LogiCORETM IP Ethernet AVB Endpoint v2.
Xilinx is providing this product documentation, hereinafter “Information,” to you “AS IS” with no warranty of any kind, express or implied. Xilinx makes no representation that the Information, or any particular implementation thereof, is free from any claims of infringement. You are responsible for obtaining any rights you may require for any implementation based on the Information. All specifications are subject to change without notice.
Table of Contents Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Schedule of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schedule of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 13 Preface: About This Guide Guide Contents . . . . . . . . . . . . . . . .
Chapter 4: Generating the Core Ethernet AVB GUI Page 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Component Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Core Delivery Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Ethernet AVB GUI Page 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 8: Real Time Clock and Time Stamping Real Time Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 RTC Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Clock Outputs Based on the Synchronized RTC Nanoseconds Field . . . . . . . . . . . . . 79 Time Stamping Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 14: Quick Start Example Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generating the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementing the Example Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simulating the Example Design . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 16: Detailed Example Design (EDK format) Directory and File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . / . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /doc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
www.xilinx.
Schedule of Figures Chapter 1: Introduction Chapter 2: Licensing the Core Chapter 3: Overview of Ethernet Audio Video Bridging Figure 3-1: Example AVB Home Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Figure 3-2: Example Ethernet AVB Endpoint System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Chapter 4: Generating the Core Figure 4-1: GUI Page 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 9: Precise Timing Protocol Packet Buffers Figure 9-1: Tx PTP Packet Buffer Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Figure 9-2: Rx PTP Packet Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Chapter 10: Configuration and Status Figure 10-1: Single Read Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Figure 10-2: Single Write Transaction . . .
Chapter 16: Detailed Example Design (EDK format) Appendix A: RTC Time Stamp Accuracy Figure A-1: RTC Periodic Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Figure A-2: RTC Sampling Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Figure A-3: Sampling Position Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Figure A-4: Overall Time Stamp Accuracy . . . .
www.xilinx.
Schedule of Tables Chapter 1: Introduction Chapter 2: Licensing the Core Chapter 3: Overview of Ethernet Audio Video Bridging Chapter 4: Generating the Core Table 4-1: XCO File Values and Default Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Chapter 5: Core Architecture Table 5-1: Clocks and Resets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Table 5-2: Legacy Traffic Signals: Transmitter Path . . . . . . . . . .
Table 10-7: Seconds Field Offset bits [31:0] (PLB_base_address + 0x2808) . . . . . . . . . . . . 95 Table 10-8: Seconds Field Offset bits [47:32] (PLB_base_address + 0x280C) . . . . . . . . . . 95 Table 10-9: RTC Increment Value Control Register (PLB_base_address + 0x2810). . . . . 95 Table 10-10: Current RTC Nanoseconds Value (PLB_base_address + 0x2814). . . . . . . . .
Chapter 16: Detailed Example Design (EDK format) Table 16-1: Project Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Table 16-2: Component Name Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Table 16-3: Doc Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Table 16-4: Driver Data Directory . . . . . . . . . . . . . . . . . . .
www.xilinx.
Preface About This Guide The LogiCORE™ IP Ethernet AVB User Guide provides information about the Ethernet Audio Video Bridging (AVB) Endpoint core, including how to customize, generate, and implement the core in supported Xilinx FPGA families. Guide Contents This guide contains the following chapters: • Preface, “About this Guide” introduces the organization and purpose of this guide and the conventions used in this document.
Preface: About This Guide • Chapter 13, “Software Drivers” describes the function of the software drivers delivered with the core. • Chapter 14, “Quick Start Example Design”Chapter 3, “Quick Start Example Design” provides instructions to quickly generate the core and run the example design through implementation and simulation using the default settings.
Conventions Convention Meaning or Use Example A list of items from which you must choose one or more lowpwr ={on|off} Separates items in a list of choices lowpwr ={on|off} User-defined variable or in code samples Vertical ellipsis . . . Repetitive material that has been omitted IOB #1: Name = QOUT’ IOB #2: Name = CLKIN’ . . . Horizontal ellipsis . . . Repetitive material that has been omitted allow block block_name loc1 loc2 ...
Preface: About This Guide List of Abbreviations The following table describes acronyms used in this manual. Acronym 20 Spelled Out AV Audio Video AVB Audio Video Bridging BMCA Best Master Clock Algorithm CRC Cyclic Redundancy Check DA Destination Address DMA Direct Memory Access DSP Digital Signal Processor EDK Embedded Development Kit EMAC Ethernet MAC FCS Frame Check Sequence FIFO First In First Out FPGA Field Programmable Gate Array.
Conventions Acronym Spelled Out PHY physical-side interface PHYAD Physical Address PLB Processor Local Bus PTP Precise Timing Protocol REGAD Register Address RTC Real Time Clock RO Read Only R/W Read/Write Rx Receive SFD Start of Frame Delimiter SRP Stream Reservation Protocol TEMAC Tri-Mode Ethernet MAC TCP/IP Transmission Control Protocol / Internet Protocol.
Preface: About This Guide 22 www.xilinx.
Chapter 1 Introduction This chapter introduces the core and provides related information including recommended design experience, additional resources, technical support, and how to submit feedback to Xilinx. The Ethernet AVB Endpoint core is a fully verified solution that supports Verilog-HDL and VHDL. In addition, the example design in this guide is provided in both Verilog and VHDL formats.
Chapter 1: Introduction Recommended Design Experience Although the Ethernet AVB Endpoint core is a fully verified solution, the challenge associated with implementing a complete design varies depending on the configuration and functionality of the application. For best results, previous experience building highperformance, pipelined FPGA designs using Xilinx implementation software and user constraint files (UCFs) is recommended.
Feedback Document For comments or suggestions about this document, submit a WebCase from www.xilinx.com/support/clearexpress/websupport.htm/ Be sure to include the following information: • Document title • Document number • Page number(s) to which your comments refer • Explanation of your comments Ethernet AVB Endpoint User Guide UG492 July 23, 2010 www.xilinx.
Chapter 1: Introduction 26 www.xilinx.
Chapter 2 Licensing the Core This chapter provides instructions for obtaining a license key for the Ethernet AVB Endpoint core, which you must do before using the core in your designs. The Ethernet AVB Endpoint core is provided under the terms of the Xilinx Core Site License Agreement. Before you Begin This chapter assumes that you have installed the required Xilinx® ISE® Design Suite version following the instructions provided by the Xilinx ISE Installation, Licensing and Release Notes Guide, www.xilinx.
Chapter 2: Licensing the Core Full The Full license key is available when you purchase a license for the core and provides full access to all core functionality both in simulation and in hardware, including: • Functional simulation support • Back annotated gate-level simulation support • Full implementation support including place and route and bitstream generation • Full functionality in the programmed device with no time outs Obtaining Your License Key This section contains information about obta
Chapter 3 Overview of Ethernet Audio Video Bridging Figure 3-1 illustrates a potential home network, consisting of wired (ethernet) and wireless components, which utilize the technology being defined by the IEEE802.1 Audio Video Bridging Task Group. This illustrates potential audio/video talkers (for example, a Cable or Satellite Content Provider, or home MP3 player) and a number of potential listeners (for example TV sets which may exist in several rooms).
Chapter 3: Overview of Ethernet Audio Video Bridging To understand the requirements of this network, we must differentiate between certain types of data: • Audio and Video streaming data, referred to in this document as AV traffic. Requires a good quality of service to avoid, for example, TV picture breakup, and must be transferred reliably and with guaranteed low latency. • Other data, referred to in this document as legacy traffic.
AVB Specifications P802.1Qav This specification defines the mechanism for queuing and forwarding AV traffic from a talker to a listener across the network. This can involve several network hops (network bridge devices that the data must pass through). P802.1Qav is also responsible for enforcing the 75% maximum bandwidth restriction across each link of the network that can be reserved for the AV traffic. Only a subset of the P802.
Chapter 3: Overview of Ethernet Audio Video Bridging P802.1Qat This specification defines a Stream Reservation Protocol (SRP) which must be used over the AVB network. Every listener that intends to receive audio/video AV traffic from a talker must make a request to reserve that bandwidth. Both the talker and every bridge device that exists between the talker and the listener has the right to decline this request.
Typical Implementation Figure 3-2 illustrates that the Ethernet AVB Endpoint core supports the two main types of data interfaces at the client side: 1. The AV traffic interface is intended for the Quality of Service audio/video data. Illustrated are a number of audio/video sources (for example, a DVD player), and a number of audio/video sinks (for example, a TV set). The Ethernet AVB Endpoint gives priority to the AV traffic interface over the legacy traffic interface, as dictated by IEEE P802.
Chapter 3: Overview of Ethernet Audio Video Bridging 34 www.xilinx.
Chapter 4 Generating the Core The Ethernet AVB Endpoint core is fully configurable using the CORE Generator™ software, which provides a Graphical User Interface (GUI) for defining parameters and options. For help starting and using the CORE Generator software, see the documentation supplied with the ISE® software, including the CORE Generator User Guide, available from www.xilinx.com/support/software_manuals.htm.
Chapter 4: Generating the Core Component Name The component name is used as the base name of the output files generated for the core. Names must begin with a letter and must be composed from the following characters: a through z, 0 through 9 and “_”.
Ethernet AVB GUI Page 2 Ethernet AVB GUI Page 2 Figure 4-2 shows page 2 of the Ethernet AVB Endpoint GUI customization screen. This page provides options for configuring the “PLB Interface” of the core. This option is only required when generating in the Standard CORE Generator software format. X-Ref Target - Figure 4-2 Figure 4-2: GUI Page 2 Number of PLB Masters The Ethernet AVB Endpoint core is a PLB slave. On the connected PLB, there may be several PLB Masters.
Chapter 4: Generating the Core Parameter Values in the XCO File XCO file parameter names and their values are identical to the names and values shown in the GUI. Table 4-1 shows the XCO file parameters and values and summarizes the GUI defaults.
Chapter 5 Core Architecture As described in Chapter 4, “Generating the Core”, the core can be generated in one of two formats, the functionality of which is described in this chapter: • “Standard CORE Generator Format” (provided for the standard ISE® software environment) This option will deliver the core in the standard CORE Generator™ output format, as used by many other cores including previous versions of this core and all other Ethernet LogiCORE™ IP solutions.
Chapter 5: Core Architecture Standard CORE Generator Format Figure 5-1 illustrates the functional blocks of the Ethernet AVB Endpoint core when it is generated in standard CORE Generator format. As illustrated, this is intended to be connected to the LogiCORE IP Tri-Mode Ethernet MAC (or to the LogiCORE IP Embedded Ethernet Wrappers available in certain Virtex devices). Each of the functional blocks illustrated will be introduced in the following sections of this chapter.
EDK pcore Format EDK pcore Format Figure 5-2 illustrates the functional blocks of the Ethernet AVB Endpoint core when it is generated in EDK pcore format. As illustrated, this is intended to be connected to the XPS LocalLink Tri-Mode Ethernet MAC. Each of the functional blocks illustrated will be introduced in the following sections of this chapter. However, observe from the figure that: • The xps_ll_temac contains its own PLB interface.
Chapter 5: Core Architecture Functional Block Description The following functional blocks described in the following sections are illustrated in Figure 5-1 and Figure 5-2. PLB Interface The core provides a PLB version 4.6 interface as its configuration port to provide easy integration with the Xilinx Embedded Development Kit and access to an embedded processor (MicroBlaze™ or PowerPC®), which is required to run the “Software Drivers.
Functional Block Description Tx Arbiter Data for transmission over an AVB network can be obtained from three types of sources: 1. AV Traffic. For transmission from the AV Traffic I/F of the core. 2. Precise Timing Protocol (PTP) Packets. Initiated by the software drivers using the dedicated hardware “Tx PTP Packet Buffers.” 3. Legacy Traffic. For transmission from the Legacy Traffic I/F of the core. The transmitter (Tx) arbiter must prioritize these packets.
Chapter 5: Core Architecture Precise Timing Protocol Blocks The various hardware Precise Timing Protocol (PTP) blocks within the core provide the dedicated hardware to implement the IEEE P802.1AS specification. However, the full functionality is only achieved using a combination of these hardware blocks coupled with functions provided by the “Software Drivers” (run on an embedded processor).
Functional Block Description RTC A significant component of the PTP network wide timing synchronization mechanism is the Real Time Counter (RTC), which provides the common time of the network. Every device on the network will maintain its own local version.
Chapter 5: Core Architecture Software Drivers Software Drivers are delivered with the Ethernet AVB Endpoint core. These drivers provide functions which utilize the dedicated hardware within the core for the PTP IEEE P802.1AS specification.
Core Interfaces Core Interfaces All ports of the core are internal connections in FPGA fabric. All clock signals are inputs and no clock resources are used by the core. This enables clock circuitry to be implemented externally to the core netlist, providing full flexibility for clock sharing with other custom logic. Clocks and Reset Table 5-1 defines the clock and reset signals which are required by the Ethernet AVB Endpoint core.
Chapter 5: Core Architecture Legacy Traffic Interface Legacy Traffic Transmitter Path Signals Table 5-2 defines the core client-side legacy traffic transmitter signals. These signals are used to transmit data from the legacy client logic into the core. All signals are synchronous to the MAC transmitter clock, tx_clk, which must be qualified by the corresponding clock enable, tx_clk_en (see “Clocks and Resets”).
Core Interfaces Table 5-3: Legacy Traffic Signals: Receiver Path Signal Direction Description legacy_rx_frame_good Output Asserted at the end of frame reception to indicate that the frame should be processed by the MAC client. legacy_rx_frame_bad Output Asserted at the end of frame reception to indicate that the frame should be discarded by the MAC client: either the frame contained an error, or it was intended for the PTP or AV traffic channel.
Chapter 5: Core Architecture AV Traffic Receiver Path Signals Table 5-5 defines the core client side AV traffic receiver signals, used by the core to transfer data to the AV client. All signals are synchronous to the MAC receiver clock, rx_clk, which must be qualified by the corresponding clock enable, rx_clk_en (see “Clocks and Resets”). Table 5-5: AV Traffic Signals: Receiver Path Signal Direction Description av_rx_data[7:0] Output AV frame data received is supplied on this port.
Core Interfaces MAC Receiver Interface These signals connect directly to the identically named Tri-Mode Ethernet MAC signals and are synchronous to rx_clk Table 5-7: Tri-Mode Ethernet MAC Receiver Interface Signal Direction Description rx_data[7:0] Input Frame data received is supplied on this port.
Chapter 5: Core Architecture Table 5-8: Tri-Mode Ethernet MAC Host Interface (Configuration/Status) Signal Direction Description host_miim_rdy Input When high, the MAC has completed its MDIO transaction host_stats_lsw_rdy Input Signal provided by the Ethernet Statistics core to indicate that the lower 32-bits of the statistic counter value is present on the host_rd_data_stats[31:0] port. If the statistics core is not used, then connect to logic 0.
Core Interfaces PLB Interface Table 5-9 defines the signals on the PLB bus. For detailed information, see the IBM PLB specification. Shaded rows represent signals not used by this core; inputs are ignored and outputs are tied to a constant. These signals are synchronous to PLB_clk; see “Clocks and Resets” for additional information.
Chapter 5: Core Architecture Table 5-9: PLB Signals (Cont’d) PIN Name 54 Direction Description PLB_wrPendPri[0:1] Input Unused. PLB pending read bus request indicator. PLB_reqPri[0:1] Input Unused. PLB request priority. Sl_addrAck Output Slave address acknowledge Sl_SSize[0:1] Output Slave data bus size. Sl_wait Output Slave wait indicator. Sl_rearbitrate Output Slave rearbitrate bus indicator. Not used, tied to logic 0.
Core Interfaces Interrupt Signals Table 5-10 defines the interrupt signals asserted by the core. All interrupts are active high and are automatically asserted. All interrupts, required by the “Software Drivers” delivered with the core, are cleared by software access to an associated configuration register. It is recommended that these interrupts are routed to the input of an EDK Interrupt Controller module as part of the embedded processor subsystem.
Chapter 5: Core Architecture PTP Signals Table 5-11 defines the signals which are output from the core by the “Precise Timing Protocol Blocks.” These signals are provided for reference only and may be used by an application. For example, the 1722 Packet Managers, as illustrated in Figure 3-2, require the following: • clk8k: this marks the class measurement interval to be used for traffic shaping for SR class A AV traffic.
Chapter 6 Ethernet AVB Endpoint Transmission As illustrated in Figure 5-1, data for transmission over an AVB network can be obtained from three types of sources: 1. AV Traffic. For transmission from the “Tx AV Traffic I/F” of the core. 2. Precise Timing Protocol (PTP) Packets. Initiated by the software drivers using the dedicated hardware “Tx PTP Packet Buffer.” 3. Legacy Traffic. For transmission from the “Tx Legacy Traffic I/F” of the core.
Chapter 6: Ethernet AVB Endpoint Transmission Error Free Legacy Frame Transmission X-Ref Target - Figure 6-1 tx_clk tx_clk_enable legacy_tx_data[7:0] DA SA L/T DATA legacy_tx_data_valid legacy_tx_ack legacy_tx_underrun Figure 6-1: Normal Frame Transmission across the Legacy Traffic Interface Figure 6-1 illustrates the timing of a normal frame transfer.
Tx AV Traffic I/F Errored Legacy Frame Transmission X-Ref Target - Figure 6-2 tx_clk tx_clk_enable legacy_tx_data[7:0] DA SA L/T DATA legacy_tx_data_valid legacy_tx_ack legacy_tx_underrun Figure 6-2: Legacy Frame Transmission with Underrun The legacy_tx_underrun is provided to give full backwards compatibility between the Legacy Traffic I/F and the client interface of the Tri-Mode Ethernet MAC.
Chapter 6: Ethernet AVB Endpoint Transmission X-Ref Target - Figure 6-3 tx_clk tx_clk_enable av_tx_data[7:0] DA SA L/T DATA DA av_tx_data_valid av_tx_done av_tx_ack Figure 6-3: Normal Frame Transmission across the AV Traffic Interface Figure 6-3 illustrates the timing of a normal frame transfer. When the AV client initiates a frame transmission, it places the first column of data onto the av_tx_data[7:0] port and asserts a logic 1 onto av_tx_valid.
Tx Arbiter Tx Arbiter Overview As illustrated in Figure 5-1, data for transmission over an AVB network can be obtained from three types of sources: 1. AV Traffic. For transmission from the AV Traffic I/F of the core. 2. Precise Timing Protocol (PTP) Packets. Initiated by the software drivers using the dedicated hardware “Tx PTP Packet Buffer.” 3. Legacy Traffic. For transmission from the Legacy Traffic I/F of the core.
Chapter 6: Ethernet AVB Endpoint Transmission X-Ref Target - Figure 6-4 increasing credit sendSlope idleSlope hiLimit credits withdrawn when no frames are waiting credit=0 when no frames are waiting increasing time 0 loLimit number of AV queued frames conflicting legacy traffic present, so queued AV frame is not transmitted until conflicting legacy frame has been transmitted 1 0 transmitting AV frame TRUE FALSE transmitting Legacy frame TRUE FALSE Figure 6-4: Credit-based Shaper Operation Figu
Tx Arbiter • During AV traffic transmission, credit is removed at a rate defined by the sendSlope. • The hiLimit and loLimit settings impose a fixed range on the possible values of credit. If the available credit hits one of these limits, it will not exceed, but saturate at the magnitude of that limit. These limits are fixed in the netlist to ensure that the interface is not used incorrectly.
Chapter 6: Ethernet AVB Endpoint Transmission hiLimit The general equation is: hiLimitValue = 2000 x idleSlopeValue In this general equation, the value of 2000 is obtained from the maximum number of bytes which may be present in legacy frames (an Envelope frame as defined in IEEE802.3 can be of size 2000 bytes).
Chapter 7 Ethernet AVB Endpoint Reception Rx Splitter The input to the Rx splitter (see Figure 5-1) is connected directly to the client Receive (Rx) interface of the connected Ethernet MAC. Received data from an AVB network can be of three types: • Precise Timing Protocol (PTP) Packets. Routed to the dedicated hardware “Rx PTP Packet Buffer” which can be accessed by the “Software Drivers.” PTP packets are identified by searching for a specific MAC Destination Address. • AV Traffic.
Chapter 7: Ethernet AVB Endpoint Reception Error Free Legacy Frame Reception X-Ref Target - Figure 7-1 rx_clk rx_clk_enable legacy_rx_data[7:0] DA SA L/T DATA legacy_rx_data_valid legacy_rx_frame_good legacy_rx_frame_bad Figure 7-1: Normal Frame Reception across the Legacy Traffic Interface Figure 7-1 illustrates the timing of a normal inbound error free frame transfer that has been accepted by the “Legacy MAC Header Filters” The legacy client must be prepared to accept data at any time; there i
Rx Legacy Traffic I/F Errored Legacy Frame Reception X-Ref Target - Figure 7-2 rx_clk rx_clk_enable legacy_rx_data[7:0] DA SA VLAN legacy_rx_data_valid legacy_rx_frame_good legacy_rx_frame_bad Figure 7-2: Errored Frame Reception across the Legacy Traffic Interface As illustrated in Figure 7-2, reception of any frame in which the legacy_rx_frame_bad is asserted (in place of legacy_rx_frame_good) indicates that this frame must be discarded by the Legacy client; it was either received with errors or
Chapter 7: Ethernet AVB Endpoint Reception X-Ref Target - Figure 7-3 rx_clk rx_clk_enable legacy_rx_data[7:0] DA SA L/T DATA legacy_rx_data_valid legacy_rx_frame_good legacy_rx_frame_bad legacy_rx_filter_match[0] legacy_rx_filter_match[1] legacy_rx_filter_match[2] legacy_rx_filter_match[3] legacy_rx_filter_match[4] legacy_rx_filter_match[5] legacy_rx_filter_match[6] legacy_rx_filter_match[7] Figure 7-3: Normal Frame Reception: Address Filter Match Figure 7-3 illustrates Legacy frame receptio
Rx Legacy Traffic I/F MAC Header Filter Configuration The MAC Header Filters can be enabled or disabled by using the “Rx Filtering Control Register.” This contains a Promiscuous Mode bit, which: • when enabled allows all frames to be received on the Legacy Rx Traffic I/F. • when disabled only allows frames to be received on the Legacy Rx Traffic I/F that contain a MAC Header that has matched at least one of the eight individual MAC Header Filters.
Chapter 7: Ethernet AVB Endpoint Reception Single MAC Header Filter Usage Examples Full Destination Address (DA) Match X-Ref Target - Figure 7-4 rx_clk rx_clk_enable legacy_rx_data[7:0] DA VLAN SA L/T DATA Figure 7-4: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x05 0xFF 0x00 0x04 0xFF 0x00 0x03 0xFF Match against DA 0x00 0x01 0x02 0xFF 0xDA Match Enable Register 0xFF Match Pattern Register 0xFF legacy_rx_data_valid Don’t-cares Filtering of Frames with a Full DA Match The example il
Rx Legacy Traffic I/F Partial Destination Address (DA) Match X-Ref Target - Figure 7-5 rx_clk rx_clk_enable legacy_rx_data[7:0] DA VLAN SA L/T DATA Figure 7-5: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x03 0x1F Match against partial DA 0x00 0x01 0x02 0xFF 0xDA Match Enable Register 0xFF Match Pattern Register 0xFF legacy_rx_data_valid Don’t-cares Filtering of Frames with a Partial DA Match The example illustrated in Figure 7-5 shows a single MAC Header Filter
Chapter 7: Ethernet AVB Endpoint Reception VLAN Priority Match X-Ref Target - Figure 7-6 rx_clk rx_clk_enable legacy_rx_data[7:0] DA VLAN SA L/T DATA Figure 7-6: 0x20 0x00 0x00 0xE0 0x00 0x00 0xFF 0x81 Don’t-cares 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Match Enable Register 0x00 Match Pattern Register 0xFF legacy_rx_data_valid VLAN priority filter Filtering of VLAN Frames with a Specific Priority Value The example illustrated in Figure 7-6 shows a single MAC Header Fil
Rx AV Traffic I/F Rx AV Traffic I/F The signals forming the Rx AV Traffic I/F are defined in Table 5-5. all signals are synchronous to the Tri-Mode Ethernet MAC receiver clock, rx_clk, which must always be qualified by the corresponding clock enable, rx_clk_en (see Table 5-1). This interface is intentionally identical to the legacy receiver interface (there is a one-to-one correspondence between signal names when the legacy_ prefix is exchanged for the av_ prefix).
Chapter 7: Ethernet AVB Endpoint Reception Errored AV Traffic Reception X-Ref Target - Figure 7-8 rx_clk rx_clk_enable av_rx_data[7:0] DA SA VLAN av_rx_valid av_rx_frame_good av_rx_frame_bad Figure 7-8: Errored Frame Reception across the AV Traffic Interface As illustrated in Figure 7-8, reception of any frame in which the av_rx_frame_bad is asserted (in place of av_rx_frame_good) indicates that this frame must be discarded by the AV client; it was either received with errors or was not intended
Chapter 8 Real Time Clock and Time Stamping This chapter considers two of the logical components that are partially responsible for the AVB timing synchronization protocol. • “Real Time Clock” • “Time Stamping Logic” These are both described in this chapter as they are closely related. Real Time Clock A significant component of the PTP network wide timing synchronization mechanism is the Real Time Counter (RTC), which provides the common time of the network.
Chapter 8: Real Time Clock and Time Stamping Conceptually, the RTC is not related to the frequency of the clock used to increment it. A configuration register within the core provides a configurable increment rate for this counter: this increment register,“RTC Increment Value Control Register,” is for this reason simply programmed with the value of the RTC Reference clock period which is being used to increment the RTC.
Real Time Clock RTC Implementation Increment of Nanoseconds Field Figure 8-2 illustrates the implementation used to create the RTC nanoseconds field. This is performed by the use of an implementation specific 20-bit sub-nanoseconds field as illustrated. The nanoseconds and sub-nanoseconds fields can be considered to be concatenated together. All RTC logic within the core is synchronous to the RTC Reference Clock, rtc_clk.
Chapter 8: Real Time Clock and Time Stamping There are two stages to the implementation: (Step 1) Controlled Frequency RTC The RTC Increment Value illustrated in Figure 8-2 is set directly from the “RTC Increment Value Control Register.” The upper 6 bits of this register align with the lower 6 bits of the RTC nanoseconds field. The lower 20-bits of the RTC Increment Value align with the 20-bit sub-nanoseconds field.
Time Stamping Logic Clock Outputs Based on the Synchronized RTC Nanoseconds Field The clk8k (8 kHz clock) output, derived from the Synchronized RTC, is provided as an output from the core. The synchronized RTC counter, unlike the controlled frequency version, has no long-term drift (assuming the provided software drivers are used correctly). Therefore, the clk8k signal will be synchronized exactly to the network RTC frequency.
Chapter 8: Real Time Clock and Time Stamping Time Stamp Sampling Position of MAC Frames A time stamp value should be sampled at the beginning of the first symbol following the Start of Frame Delimiter (SFD) of the Ethernet MAC frame as seen on the PHY. This is illustrated in Figure 8-3.
IEEE1722 Real Time Clock Format Because the Xilinx Tri-Mode Ethernet MACs have a known fixed latency, the time stamps taken can easily be translated into the equivalent GMII position to comply with the standard. This is performed in the software drivers where the MAC transmitter and receiver latencies are held in #defines in a header file. The software drivers also contain placeholder #defines for users to input the PHY-specific latency values for the PHYs used in the system.
Chapter 8: Real Time Clock and Time Stamping 82 www.xilinx.
Chapter 9 Precise Timing Protocol Packet Buffers This chapter considers two of the logical components which are partly responsible for the AVB timing synchronization protocol. • “Tx PTP Packet Buffer” • “Rx PTP Packet Buffer” These are both described in this chapter as they are closely related. Tx PTP Packet Buffer The Tx PTP packet buffer is illustrated in Figure 9-1. This packet buffer provides working memory to hold the PTP frames which are required for transmission.
Chapter 9: Precise Timing Protocol Packet Buffers Despite the logic and formatting of each individual PTP buffer being identical, the block RAM is pre-initialized at device configuration to hold template copies of each of the PTP frames, as indicated in Figure 9-1. This shows that the first seven memory segments are in use. PTP Buffer number 8 is currently unused and could therefore be used by proprietary applications.
Rx PTP Packet Buffer Rx PTP Packet Buffer The Rx PTP packet buffer is illustrated in Figure 9-2. This provides working memory to hold each received PTP frame. The software drivers, via the PLB configuration bus, can then read and decode the contents of the received PTP frames. The PTP packet buffer is implemented in dual-port block RAM. Port A of the block RAM is connected to the PLB configuration bus: all addresses in the buffer can be read (writes are not allowed).
Chapter 9: Precise Timing Protocol Packet Buffers The “Software Drivers” provided with the core, using the PLB and dedicated interrupt, will use this interface to decode, and then act on, the received PTP packet information.
Chapter 10 Configuration and Status This chapter provides general guidelines for configuring and monitoring the Ethernet AVB Endpoint core, including an introduction to the PLB configuration bus and a description of the core management registers.
Chapter 10: Configuration and Status X-Ref Target - Figure 10-1 PLB_clk PLB_RNW 11111111 PLB_BE[0:7] PLB_size[0:3] 0000 PLB_type[0:2] 000 PLB_abort A0 PLB_ABus[0:31] PLB_PAValid SI_wait SI_addrAck PLB_wrDBus[0:31] SI_wrDAck SI_wrComp PLB_wrBurst SI_rdDBus[0:31] 0000 SI_rdWrAddr[0:3] 0000 D(A0) 0000 0000 SI_rdDAck SI_rdComp PLB_rdBurst Figure 10-1: 88 Single Read Transaction www.xilinx.
Processor Local Bus Interface Single Write Transaction Figure 10-2 illustrates a single write data transfer on the PLB. Note the following: • Wait states can be added to the Address cycle by asserting Sl_wait and delaying Sl_addrAck. • Wait states can be inserted in the Write sample by delaying the assertion of Sl_wrDAck.
Chapter 10: Configuration and Status PLB Address Map and Register Definitions Figure 10-3 displays an overview of the Address Space occupied by the Ethernet AVB Endpoint core on the PLB. Common across all addressable space, each unique PLB address value references a single byte of data.
PLB Address Map and Register Definitions The entire address space is now described in two sections: • “Ethernet AVB Endpoint Address Space” • “Tri-Mode Ethernet MAC Address Space” (which can be addressed through the Ethernet AVB Endpoint core Address Space). This address is only present when the core is generated in “Standard CORE Generator Format”.
Chapter 10: Configuration and Status Ethernet AVB Endpoint Address Space Rx PTP Packet Buffer Address Space The Address space of the “Rx PTP Packet Buffer” is 4k bytes, from PLB_base_address to (PLB_base_address + 0x0FFF). This represents the size of a single Virtex®-5 FPGA block RAM pair (4k bytes). Every byte of this Block RAM can be read from the PLB. See “Rx PTP Packet Buffer” for operation.
PLB Address Map and Register Definitions Rx PTP Packet Control Register Table 10-2 defines the associated control register of the “Rx PTP Packet Buffer,” used by the “Software Drivers” to monitor the position of the most recently received PTP frame.: Table 10-2: Rx PTP Packet Buffer Control Register (PLB_base_address + 0x2004) Bit no 0 Default 0 Access WO Description rx_clear.
Chapter 10: Configuration and Status Tx Arbiter Send Slope Control Register The sendSlope variable is defined in IEEE P802.1 Qav to be the rate of change of credit, in bits per second, when the value of credit is decreasing (during AV packet transmission). Together with the “Tx Arbiter Idle Slope Control Register,” registers define the maximum limit of the bandwidth that is reserved for AV traffic; this will be enforced by the “Tx Arbiter.
PLB Address Map and Register Definitions This register and the registers defined in Table 10-6 and in Table 10-8 are linked. These three offset values will be loaded into the RTC counter logic simultaneously following a write to the nanosecond offset register defined in Table 10-6. Table 10-7: Seconds Field Offset bits [31:0] (PLB_base_address + 0x2808) Bit no Default Access Description 31-0 0 R/W 32-bit offset value for the RTC seconds field (bits 31-0).
Chapter 10: Configuration and Status This register and the registers defined in Table 10-11 and in Table 10-12 are linked. When this nanoseconds value register is read, the entire RTC (including the seconds field) is sampled. Table 10-10: Current RTC Nanoseconds Value (PLB_base_address + 0x2814) Bit no Default Access 29-0 0 RO Description Current Value of the synchronized RTC nanoseconds field.
PLB Address Map and Register Definitions Phase Adjustment Register Table 10-14 describes the Phase Adjustment Register, which has units of nanoseconds. This value is used to correct the 8k clock generation circuit when a new nanosecond offset value is written to the RTC. It additionally could be used to apply a phase offset to the clk8k signal.
Chapter 10: Configuration and Status Table 10-15: Software Reset Register (Address at PLB_base_address + 0x2828) Bit Number 3 Default 0 Access WO Description PTP Receiver logic reset. When written with a '1', forces the PTP receiver logic of the core to be reset. This is a subset of the full receiver path reset of bit 1. This reset does not affect PTP receiver configuration settings. If read, always returns 0.
PLB Address Map and Register Definitions Table 10-16: MAC Header Filter Configuration Registers (Cont’d) Address Default Access PLB_base_address 0x00000000 R/W Description Match Pattern: Ethernet frame bits 96 to 127 32 bit pattern to match against the Ethernet frame bits 96 to 127. + 0x3000 + (filter# * 0x20) For frames with a VLAN tag, match pattern bits[31:0] can be matched against the full VLAN field.
Chapter 10: Configuration and Status Tri-Mode Ethernet MAC Address Space When the core is generated in “EDK pcore Format” for import into EDK and connection to the xps_ll_temac, the address space defined in this section is not included and the address space will return 0s for a read and all writes will be ignored.
PLB Address Map and Register Definitions MAC MDIO Registers The Tri-Mode Ethernet MAC has MDIO master capability.
Chapter 10: Configuration and Status 102 www.xilinx.
Chapter 11 Constraining the Core This chapter defines the Ethernet AVB Endpoint core constraints. An example user constraints file (UCF) is provided for the core and the HDL example design.
Chapter 11: Constraining the Core PERIOD Constraints for Clock Nets PLB_clk The clock provided to PLB_clk must be constrained to the appropriate frequency. Note the frequency range of the embedded processor to which this bus is connected. For example, the maximum clock speed of the MicroBlaze™ processor is 100 MHz.
Required Constraints rtc_clk The RTC can be incremented from any available clock frequency that is greater than the AVB standards defined minimum of 25 MHz. However, the faster the frequency of the clock, the smaller will be the step increment and the smoother will be the overall RTC increment rate. Xilinx recommends clocking the RTC logic at 125 MHz because this is a readily available clock source (obtained from the transmit clock source of the Ethernet MAC at 1 Gbps speed).
Chapter 11: Constraining the Core INST "*top/rx_rtc_sample_inst/sample_taken_toggle" TNM = FFS "rx_sample_taken"; INST "*top/rx_rtc_sample_inst/resync_sample_taken_toggle/data_sync" TNM = FFS "rx_sample_taken_resync"; TIMESPEC "ts_rx_sample_taken" = FROM "rx_sample_taken" TO "rx_sample_taken_resync" TIG; INST "*top/rx_rtc_sample_inst/timestamp*" TNM = FFS "rx_timestamp"; TIMESPEC "ts_rx_timestamp_route" = FROM "rx_timestamp" TO "FFS" 8 ns DATAPATHONLY; # clock domain crossing constraints for Rx PTP Packet
Required Constraints INST "*top/avb_configuration_inst/vlan_priority_a_int*" TNM = FFS "vlan_priority_a"; INST "*top/rx_splitter_inst/vlan_priority_a_sample*" TNM = FFS "vlan_priority_a_sample"; TIMESPEC "ts_vlan_priority_a_sample" = FROM "vlan_priority_a" TO "vlan_priority_a_sample" TIG; INST "*top/avb_configuration_inst/vlan_priority_b_int*" TNM = FFS "vlan_priority_b"; INST "*top/rx_splitter_inst/vlan_priority_b_sample*" TNM = FFS "vlan_priority_b_sample"; TIMESPEC "ts_vlan_priority_b_sample" = FROM "vl
Chapter 11: Constraining the Core INST "*top/avb_configuration_inst/tx_send_frame*" TNM = FFS "tx_regs_sample"; INST "*top/avb_configuration_inst/tx_sendslope_int*" TNM = FFS "tx_regs_sample"; INST "*top/avb_configuration_inst/tx_idleslope_int*" TNM = FFS "tx_regs_sample"; TIMESPEC "ts_tx_regs_sample" = FROM "cpu_bus" TO "tx_regs_sample" 24 ns DATAPATHONLY; INST "*top/avb_configuration_inst/rd_data_tx*" TNM = FFS "tx_rd_data"; INST "*top/avb_configuration_inst/cpu_rd_data*" TNM = FFS "tx_cpu_rd_data"; TIME
Required Constraints INST "*top/rtc_inst/rtc_configuration_inst/reg_nanosec_offset*" TNM = FFS "rtc_regs_sample"; INST "*top/rtc_inst/rtc_configuration_inst/reg_sec_offset*" TNM = FFS "rtc_regs_sample"; INST "*top/rtc_inst/rtc_configuration_inst/reg_epoch_offset*" TNM = FFS "rtc_regs_sample"; INST "*top/rtc_inst/rtc_configuration_inst/reg_rtc_increment*" TNM = FFS "rtc_regs_sample"; INST "*top/rtc_inst/rtc_configuration_inst/reg_offset_8k*" TNM = FFS "rtc_regs_sample"; TIMESPEC "ts_rtc_regs_sample" = FROM
Chapter 11: Constraining the Core INST "*top*generic_host_if_inst/host_toggle_reg2" TNM = FFS "host_toggle"; INST "*top*generic_host_if_inst/resync_host_toggle/data_sync" TNM = FFS "resync_host_toggle"; TIMESPEC "ts_host_toggle" = FROM "host_toggle" TO "resync_host_toggle" 8 ns DATAPATHONLY; INST "*top*generic_host_if_inst/host_rd_data_result*" TNM = FFS "host_rd_data"; INST "*top*generic_host_if_inst/cpu_rd_data*" TNM = FFS "cpu_rd_data"; TIMESPEC "ts_cpu_rd_data" = FROM "host_rd_data" TO "cpu_rd_data" 8
Chapter 12 System Integration As described in Chapter 4, “Generating the Core” and Chapter 5, “Core Architecture”, the core can be generated in one of two formats: • “Standard CORE Generator Format” This option will deliver the core in the standard CORE Generator™ output format, as used by many other cores including previous versions of this core and all other Ethernet LogiCORE™ IP solutions.
Chapter 12: System Integration LogiCORE IP Tri-Mode Ethernet MAC (Soft Core) Tri-Mode Ethernet MAC Core Generation When generating the Tri-Mode Ethernet MAC (TEMAC) core in the CORE Generator software, be sure that the following options are selected: • Management Interface. Enabled • Clock Enables. Enabled • Address Filter. Disabled See the Tri-Mode Ethernet MAC User Guide (UG138) for additional information. 112 www.xilinx.
Using the Xilinx LogiCORE IP Tri-Mode Ethernet MACs Connections Without Ethernet Statistics X-Ref Target - Figure 12-1 Ethernet AVB Endpoint Core Netlist TEMAC Block-level Wrapper (from TEMAC Example Design) pause_req pause_val[15:0] GND tx_clk tx_clk_en tx_clk tx_clk_en tx_data[7:0] tx_data_valid tx_underrun tx_ack NC NC tx_data[7:0] tx_data_valid tx_underrun tx_ack tx_collision tx_retransmit tx_ifg_delay[7:0] tx_statistics_valid NC tx_statistics_vector[31:0] NC rx_statistics_valid NC rx_statis
Chapter 12: System Integration Because the TEMAC core can often be used in different clocking modes, note the following: 114 • The Ethernet transmitter client clock domain must always be connected to the tx_clk input of the Ethernet AVB Endpoint core. Additionally, the transmitter clock enable, as used with the TEMAC, must always be connected to the tx_clk_en input of the Ethernet AVB Endpoint core.
Using the Xilinx LogiCORE IP Tri-Mode Ethernet MACs Connections Including Ethernet Statistics X-Ref Target - Figure 12-2 Ethernet AVB Endpoint Core Netlist TEMAC BLock-level Wrapper (from TEMAC Example Design) pause_req pause_val[15:0] GND tx_clk tx_clk_en tx_clk tx_clk_en tx_data[7:0] tx_data_valid tx_underrun tx_ack NC NC rx_clk rx_clk_en rx_data[7:0] rx_data_valid rx_frame_good rx_frame_bad host_opcode[1:0] host_addr[9:0] host_wr_data[31:0] host_req host_miim_sel host_miim_rdy host_rd_data_mac[31:0]
Chapter 12: System Integration LogiCORE IP Embedded Tri-Mode Ethernet MACs Virtex-5 FPGA Embedded Tri-Mode Ethernet MAC Wrapper Generation When generating the Virtex-5 FPGA Embedded Ethernet MAC Wrapper (EMAC) in the CORE Generator software, be sure that the following options are selected: • Enable EMACs. Enable only a single EMAC (from the pair) at this time • Host Type. Select Host • Speed. Select Tri-speed • Global Buffer Usage. Clock Enable • Flow Control Configuration.
Using the Xilinx LogiCORE IP Tri-Mode Ethernet MACs Connections Without Ethernet Statistics X-Ref Target - Figure 12-3 Ethernet AVB Endpoint Core Netlist Block-level Wrapper (from Virtex-5 Embedded Tri-mode Ethernet MAC Wrapper) CLIENTEMAC0PAUSEREQ CLIENTEMAC0PAUSEVAL[15:0] GND tx_clk tx_clk_en tx_data[7:0] tx_data_valid tx_underrun tx_ack NC NC TX_CLK_0 TX_CLIENT_CLK_ENABLE_0 CLIENTEMAC0TXD[7:0] CLIENTEMAC0TXDVLD CLIENTEMAC0TXUNDERRUN EMAC0CLIENTTXACK EMAC0CLIENTTXCOLLISION EMAC0CLIENTTXRETRANSMIT CL
Chapter 12: System Integration Because the EMAC core can often be used in different clocking modes, note the following: • The Ethernet transmitter client clock domain must always be connected to the tx_clk input of the Ethernet AVB Endpoint core. Additionally, the transmitter clock enable, as used with the EMAC, must always be connected to the tx_clk_en input of the Ethernet AVB Endpoint core.
Using the Xilinx LogiCORE IP Tri-Mode Ethernet MACs Figure 12-4 illustrates the connection of the Ethernet AVB Endpoint core to the EMAC when using the Ethernet Statistics core. This shares much in common with Figure 12-2; however, note the following additional points: • All of the “MAC Management Interface” output signals of the Ethernet AVB Endpoint core connect directly to the signals of both the EMAC and Ethernet Statistics cores.
Chapter 12: System Integration X-Ref Target - Figure 12-5 BRAM lmb_bram_if_cntlr Microblaze PLB xps_intc xps_uartlite Ethernet AVB Endpoint PLB TEMAC Host I/F MDIO MAC client I/F Ethernet PHY I/F interrupt_ptp_timer interrupt_ptp_tx interrupt_ptp_rx Custom AV logic Custom Legacy logic Figure 12-5: 120 AV traffic I/F Legacy traffic I/F Connection of the Ethernet AVB Endpoint Core into an Embedded Processor Sub-system www.xilinx.
Using the Xilinx LogiCORE IP Tri-Mode Ethernet MACs Figure 12-5 can be implemented using the Xilinx tool set using two methods: • “Using an EDK Project Top Level” • “Using an ISE Software Top-Level Project” Using an EDK Project Top Level X-Ref Target - Figure 12-6 EDK Tool Domain BRAM lmb_bram_if_cntlr Microblaze PLB xps_intc xps_uartlite pcore: plb_port pcore pcore Ethernet AVB Endpoint PLB TEMAC Host I/F MDIO MAC client I/F Ethernet PHY I/F interrupt_ptp_timer interrupt_ptp_tx interr
Chapter 12: System Integration In this example, the instance of the Ethernet AVB Endpoint core should be assigned a base address in the Microprocessor Hardware Specification (.mhs) file, to match that of the Ethernet AVB Endpoint “PLB Base Address” (in the generated netlist produced by the CORE Generator software). Then the AVB software drivers can be assigned to this instance in the Microprocessor Software Specification (.mss) file.
Using the Xilinx LogiCORE IP Tri-Mode Ethernet MACs Figure 12-7 shows the implementation using an ISE® software top-level project. In this hierarchy, the embedded processor subsystem is created using an EDK project containing only the blocks illustrated in the EDK tool domain block. This EDK project is not the top level of the system and is instantiated as a black box subcomponent in a standard ISE software project as illustrated.
Chapter 12: System Integration Using the Xilinx XPS LocalLink Tri-Mode Ethernet MAC The Ethernet AVB Endpoint core should be generated in the “EDK pcore Format” when connecting to the XPS LocalLink Tri-Mode Ethernet MAC core (xps_ll_temac). Introduction The xps_ll_temac is delivered with data path FIFO’s (of configurable depth), optional TCP/IP Offload Engine (TOE) logic and various other optional features, all of which can be connected to Scatter Gather Direct Memory Access (DMA) Engines.
Using the Xilinx XPS LocalLink Tri-Mode Ethernet MAC System Overview: AVB capable xps_ll_temac X-Ref Target - Figure 12-8 EDK Tool Domain BRAM lmb_bram_if_cntlr Microblaze MPMC PLB xps_intc xps_uartlite pcore Ethernet AVB Endpoint XPS_LL_TEMAC LocalLink MDIO PLB PLB interr upt_ptp_timer interrupt_ptp_tx interrupt_ptp_rx pcore Custom AV logic Figure 12-8: AV traffic I/F MAC client I/F Avb2TemacRx Temac2AVBTx Legacy traffic I/F Avb2TemacTx Temac2AVBRx Ethernet PHY I/F Connection of th
Chapter 12: System Integration Figure 12-8 illustrates the connection of the core to an embedded processor subsystem (MicroBlaze™ processor is illustrated). Observe that: • The PLB can be shared across all peripherals as illustrated. • The “Interrupt Signals” should be connected to the inputs of an interrupt controller module, for example, the xps_intc core provided with the EDK.
Using the Xilinx XPS LocalLink Tri-Mode Ethernet MAC X-Ref Target - Figure 12-9 Ethernet AVB Endpoint pcore MAC Transmitter I/F Legacy Transmitter I/F Legacy Recevier I/F tx_clk tx_clk_enable Temac0AvbTxClk Temac0AvbTxClkEn tx_data[7:0] tx_data_valid tx_underrun tx_ack Avb2Mac0TxData[7:0] Avb2Mac0TxDataValid Avb2Mac0TxUnderrun Mac02AvbTxAck rx_clk rx_clk_enable Temac0AvbRxClk Temac0AvbRxClkEn rx_data[7:0] rx_data_valid rx_frame_good rx_frame_bad MAC Receiver I/F legacy_tx_data[7:0] legacy_tx_d
Chapter 12: System Integration BEGIN xps_ll_temac PARAMETER INSTANCE = Hard_Ethernet_MAC PARAMETER C_NUM_IDELAYCTRL = 2 PARAMETER C_IDELAYCTRL_LOC = IDELAYCTRL_X0Y4-IDELAYCTRL_X1Y5 PARAMETER C_FAMILY = virtex5 PARAMETER C_PHY_TYPE = 1 PARAMETER C_TEMAC1_ENABLED = 0 PARAMETER C_BUS2CORE_CLK_RATIO = 1 PARAMETER C_TEMAC_TYPE = 0 PARAMETER C_TEMAC0_PHYADDR = 0b00001 PARAMETER HW_VER = 2.02.
Using the Xilinx XPS LocalLink Tri-Mode Ethernet MAC PARAMETER C_MEM0_HIGHADDR = 0xcc00ffff BUS_INTERFACE SPLB = mb_plb PORT reset = sys_periph_reset # Connect as per Figure 12-9 PORT tx_clk = Temac0AvbTxClk PORT tx_clk_en = Temac0AvbTxClkEn PORT rx_clk = Temac0AvbRxClk PORT rx_clk_en = Temac0AvbRxClkEn PORT tx_data = Avb2Mac0TxData PORT tx_data_valid = Avb2Mac0TxDataValid PORT tx_underrun = Avb2Mac0TxUnderrun PORT tx_ack = Mac02AvbTxAck PORT rx_data = Mac02AvbRxData PORT rx_data_valid = Mac02AvbRxDataVali
Chapter 12: System Integration 130 www.xilinx.
Chapter 13 Software Drivers Software drivers delivered with the Ethernet AVB Endpoint core provide the following functions, which utilize the dedicated hardware within the core for the Precise Timing Protocol (PTP) IEEE P802.
Chapter 13: Software Drivers Clock Slave If the core is acting as a clock slave, the local RTC is closely matched to the value and frequency of the network clock master. This is achieved, in part, by receiving the PTP Sync and Follow-Up frames transmitted across the network by the clock master (and containing the sampled RTC value of the master). The PTP mechanism also tracks the total routing delay across the network between the clock master and itself.
Software System Integration For example, in the user software, the AVB drivers can be instanced as follows: /* Allocate an instance of the XAvb device driver */ static XAvb Avb; int Status; XAvb_Config *AvbConfigPtr; . /* Initialize AVB Driver */ AvbConfigPtr = XAvb_LookupConfig(AVB_DEVICE_ID); Status = XAvb_CfgInitialize(&Avb, AvbConfigPtr, AvbConfigPtr->BaseAddress); In the previous example, the AVB_DEVICE_ID is defined in the xparameters.
Chapter 13: Software Drivers Core Initialization When Using a LogiCORE IP Tri-Mode Ethernet MAC Note: When connecting to the XPS LocalLink Tri-Mode Ethernet MAC (xps_ll_temac), available in EDK, the MAC is delivered with its own drivers and the functionality of this subsection is not required. The Xilinx LogiCORE™ IP “Tri-Mode Ethernet MACs” require initialization of the MDIO clock frequency (the MDC signal) and requires specific non-default configuration (VLAN enabled, Flow Control disabled).
Software System Integration You should also update the following #define if there is a known asymmetry in the propagation delay on the link. This #define models the per-port global variable “delayAsymmetry” as defined in IEEE P802.1AS and should be edited based on the description given in this specification. However, the current implementation uses truncated nanoseconds rather than the scaled Ns type. The value is set to 0 by default.
Chapter 13: Software Drivers * This function is the handler which will be called if the PTP drivers * identify a possible discontinuity in GrandMaster time. * This handler provides an example of how to handle this situation * but this function is application specific. * * @param CallBackRef contains a callback reference from the driver, in * this case it is the instance pointer for the AVB driver.
Chapter 14 Quick Start Example Design The quick start steps provided in this chapter let you quickly generate an Ethernet AVB Endpoint core, run the design through implementation with the Xilinx tools, and simulate the design using the provided demonstration test bench. For detailed information about the Standard CORE Generator example design, see Chapter 15, “Detailed Example Design (Standard Format).
Chapter 14: Quick Start Example Design The Ethernet AVB Endpoint example design has been tested using Xilinx® ISE® software v12.2, Cadence Incisive Enterprise Simulator (IES) v9.2, Mentor Graphics ModelSim v 6.5c, and Synopsys VCS and VCS MX 2009.12.
Generating the Core Generating the Core This section provides detailed instructions for generating the Ethernet AVB Endpoint example design core. To generate the core: 1. Start the CORE Generator™ tool. For general help with starting and using CORE Generator software on your system, see the documentation supplied with the ISE software, including the CORE Generator Guide. These documents can be downloaded from: www.xilinx.com/support/software_manuals.htm 2. Create a new project. 3.
Chapter 14: Quick Start Example Design X-Ref Target - Figure 14-2 Figure 14-2: Ethernet AVB Endpoint Core Customization Screen 7. Enter a core instance name in the Component Name field. 8. Maintain the default options on GUI page 1 so that Standard CORE Generator format is selected. 9. Click Generate to deliver the core using the default options. The default core and its supporting files, including the example design, are generated in your project directly.
Implementing the Example Design Implementing the Example Design After the core is generated, the netlists and example design can be processed by the Xilinx implementation tools. The generated output files include several scripts to assist you in running the Xilinx software. To implement the Ethernet AVB Endpoint example design core: From the CORE Generator software project directory window, type the following: Linux % cd //implement % ./implement.
Chapter 14: Quick Start Example Design Timing Simulation This section contains instructions for running a timing simulation of the Ethernet AVB Endpoint core using either VHDL or Verilog. A timing simulation model is generated when run through the Xilinx tools using the implementation script. You must implement the core before attempting to run timing simulation. To run a VHDL or Verilog timing simulation of the example design: 1. 2.
Chapter 15 Detailed Example Design (Standard Format) This chapter provides detailed information about the core when generated for the Standard CORE Generator™ software format. This option is selected from page 1 of the customization GUI and will deliver the core with the standard CORE Generator software directory structure (used by many LogiCORE™ IP systems including all other CORE Generator software Ethernet cores).
Chapter 15: Detailed Example Design (Standard Format) /drivers/v2_04_a Files for compiling the low-level drivers provided with the core drivers/avb_v2_04_a/data Data files for automatic integration into Xilinx Platform Studio drivers/avb_v2_04_a/examples An application example using the low-level driver files drivers/avb_v2_04_a/src Low-level driver source C files Directory and File Contents The core directories and their associated files are defined in the following tables.
Directory and File Contents / The directory contains the release notes file provided with the core, which may include last-minute changes and updates. Table 15-2: Component Name Directory Name Description / eth_avb_endpoint_readme.txt Core release notes file Back to Top /doc The doc directory contains the PDF documentation provided with the core.
Chapter 15: Detailed Example Design (Standard Format) Table 15-4: Example Design Directory (Cont’d) Name Description rx_frame_checker.v[hd] An HDL file which is capable of receiving Ethernet frames at maximum line rate. This will check the data contained in each Ethernet frame received against a predictable pattern. This file partners the tx_frame_stimulus file. plb_client_logic.
Directory and File Contents implement/results The results directory is created by the implement script, after which the implement script results are placed in the results directory. Table 15-6: Results Directory Name Description //implement/results routed.v[hd] Back-annotated SimPrim-based model used for timing simulation. routed.sdf Timing information for simulation.
Chapter 15: Detailed Example Design (Standard Format) Table 15-8: Functional Directory (Cont’d) Name Description wave_ncsim.sv IES macro file that opens a wave window and adds signals of interest to it. It is called by the simulate_ncsim.sh script file. simulate_vcs.sh VCS script file that compiles the Verilog sources and runs the functional simulation to completion. vcs_commands.key This file is sourced by VCS at the start of simulation; it configures the simulator. vcs_session.
Directory and File Contents /drivers/v2_04_a A directory containing the software device drivers for the Ethernet AVB Endpoint core and associated supporting files. drivers/avb_v2_04_a/data The driver data directory contains the data files for automatic generation of parameter specific files when integrated into Platform Studio. Table 15-10: Driver Data Directory Name Description //drivers/ avb_v2_04/data avb_v2_1_0.
Chapter 15: Detailed Example Design (Standard Format) drivers/avb_v2_04_a/src The driver source (src) directory contains the low-level driver source C files. Table 15-12: Driver Source Directory Description Name //drivers/ avb_v2_04/src Makefile Makefile to compile the drivers; used by Platform studio. xavb.h Main header file for the XAvb driver. The file provides the constants, type definitions and function templates which are required to initialize and run the IEEE802.
Implementation Scripts Implementation Scripts The implementation script is either a shell script or batch file that processes the example design through the Xilinx tool flow and is one of the following locations: Linux //implement/implement.sh Windows //implement/implement.bat The implement script performs the following steps: 1. HDL example design files are synthesized using XST. 2.
Chapter 15: Detailed Example Design (Standard Format) Timing Simulation The test script is a ModelSim, IES, or VCS macro that automates the simulation of the test bench and is in the following location: //simulation/timing/ The test script performs the following tasks: • Compiles the SimPrim-based gate level netlist simulation model • Compiles the demonstration test bench • Starts a simulation of the test bench using back-annotated timing information (SDF) • Opens a Wav
Example Design Top-Level Example Design HDL The following files describe the top-level example design for the Ethernet AVB Endpoint core. VHDL //example_design/_example _design.vhd Verilog //example_design/_example _design.
Chapter 15: Detailed Example Design (Standard Format) The data field of the frame is designed to create a simple 8-bit binary counter that continues seamlessly across consecutive Ethernet frames. The Ethernet Frame Stimulus block is designed to produce frames at full line rate to fully stress the core. Ethernet Frame Checker The following files describe the Ethernet Frame Checker logic. VHDL //example_design/rx_frame_checker.
Example Design PLB Module The following files describe the logic for the PLB module. VHDL //example_design/plb_client_logic.vhd Verilog //example_design/plb_client_logic.v The PLB module connects to the PLB interface of the core and performs the following functions: • Initialization. A state machine writes to the RTC configuration space to set the RTC running at the correct frequency following reset/power-up.
Chapter 15: Detailed Example Design (Standard Format) Demonstration Test Bench Figure 15-2 illustrates the Ethernet AVB Endpoint demonstration test bench, a simple VHDL or Verilog program for exercising the example design and the core.
Example Design Customizing the Test Bench Simulation Run Time The default simulation run time is set to only 40 microseconds, which can be easily extended by editing the simulation_run_time constant, set near the top of the demonstration test bench file.
Chapter 15: Detailed Example Design (Standard Format) Viewing the Simulation Wave Form The Simulation Scripts for the selected simulator automatically selects signals of interest from within the DUT and adds them to the simulator wave window. These are organized into grouped interfaces, which are identified using section headings in the wave window. Figure 15-3 illustrates the grouped interfaces selected for the Functional Simulation.
Chapter 16 Detailed Example Design (EDK format) This chapter provides detailed information about the core when generated in the Standard Embedded Development Kit (EDK) format, including a description of files and the directory structure generated. This option is selected from page 1 of the customization GUI. Please refer instead to Chapter 15, “Detailed Example Design (Standard Format).” when requiring the Standard CORE Generator™ software format.
Chapter 16: Detailed Example Design (EDK format) Directory and File Contents The core directories and their associated files are defined in the following tables. The project directory contains all the CORE Generator software project files. Table 16-1: Project Directory Name Description .ngc Top-level netlist. This is instantiated by the Verilog or VHDL example design. .xco Log file that records the settings used to generate a core.
Directory and File Contents /doc The doc directory contains the PDF documentation provided with the core. Table 16-3: Doc Directory Name Description //doc eth_avb_endpoint_ds677.pdf Ethernet AVB Endpoint Data Sheet eth_avb_endpoint_ug492.pdf Ethernet AVB Endpoint User Guide Back to Top /MyProcessorIPLib This is the route directory which should be imported into the Xilinx Embedded Development Kit.
Chapter 16: Detailed Example Design (EDK format) pcores/eth_avb_endpoint_v2_04_a/hdl/vhdl Contains a VHDL wrapper file for the core netlist to enable integration into Platform Studio. Table 16-5: Driver Data Directory Name Description //MyProcessorIPLib/pcores/ eth_avb_endpoint_v2_04/hdl/vhdl eth_avb_endpoint.vhd This is a wrapper file around the Ethernet AVB Endpoint netlist to enable dynamic PLB address assignment from within Platform Studio.
Directory and File Contents drivers/avb_v2_04_a/data The driver data directory contains the data files for automatic generation of parameter specific files when integrated into Platform Studio. Table 16-7: Driver Data Directory Name Description //MyProcessorIPLib/drivers/ avb_v2_04/data avb_v2_1_0.mdd Current MDD file used, including the version of the tools interface. avb_v2_1_0.tcl Used to provide design rule checks within Xilinx Platform Studio.
Chapter 16: Detailed Example Design (EDK format) drivers/avb_v2_04_a/src The driver source (src) directory contains the low-level driver source C files. Table 16-9: Driver Source Directory Description Name //MyProcessorIPLib/drivers/ avb_v2_04/src Makefile Makefile to compile the drivers; used by Platform Studio. xavb.h Main header file for the XAvb driver.
Importing the Ethernet AVB Endpoint Core into the Embedded Development Kit (EDK) Importing the Ethernet AVB Endpoint Core into the Embedded Development Kit (EDK) You can import a generated Ethernet AVB Endpoint netlist into an EDK project by following the usual steps to import a black box IP. See the Xilinx Platform Studio documentation for information. After importing the generated netlist, the drivers can also be linked into the software application.
Chapter 16: Detailed Example Design (EDK format) 166 www.xilinx.
Appendix A RTC Time Stamp Accuracy Time Stamp Accuracy The accuracy of the time stamps, taken by sampling the “Real Time Clock” (RTC) whenever PTP frames are transmitted or received, is essential to the Precise Timing Protocol across the network link. For this reason, the time stamps are performed in hardware.
Appendix A: RTC Time Stamp Accuracy The maximum RTC inaccuracy, per time stamp sample, is equal to the period of the RTC reference clock (in this example 40 ns). By using a high frequency RTC reference clock, a high degree of accuracy can be obtained. X-Ref Target - Figure A-1 RTC 0 40 40 0 80 80 120 120 160 160 200 200 240 240 Time (ns) -40 RTC Error (ns) Timestamp A (Error = 39 ns) Figure A-1: 168 www.xilinx.
Time Stamp Accuracy RTC Sampling Error It has to be assumed that the RTC reference clock is of a different frequency to the MAC transmitted and receiver clocks. Therefore, the RTC sampling logic has to be asynchronous. There are a number of methods to obtain a time stamp across an asynchronous clock boundary. The simplest method, is to simply pass a toggle signal from the Tx/Rx domain into the RTC reference clock domain whenever a time stamp is required.
Appendix A: RTC Time Stamp Accuracy X-Ref Target - Figure A-3 TIMING CASE 1 MAC Tx/Rx clock toggle clock boundary RTC Reference Clock Q0 Q1 Q2 Take RTC Sample Sample TIMING CASE 2 MAC Tx/Rx clock toggle clock boundary RTC Reference Clock Q0 Q1 Q2 Take RTC Sample Sample Sampling uncertainty Figure A-3: 170 Sampling Position Uncertainty www.xilinx.
Time Stamp Accuracy Accuracy Resulting from the Combined Errors The section “RTC Real Time Instantaneous Error” describes how a maximum error of one RTC reference clock period can result as a consequence of the RTC itself. The section “RTC Sampling Error” describes how the position of the time stamp request, as observed in the RTC reference clock domain, can result in one RTC reference clock period of uncertainty. Figure A-4 attempts to illustrate the result of the combination of these two types of error.
Appendix A: RTC Time Stamp Accuracy ♦ If the flip-flop samples the new value, then Timing Case 1 results. The RTC is sampled as 200 (resulting in an error of 39 ns which is entirely due to the “RTC Real Time Instantaneous Error”). ♦ If the flip-flop samples the old value, then Timing Case 2 results. The RTC is sampled 1 RTC reference clock period later as 240 (resulting in an error of only 1 ns).
