DMA Core Reference Guide

Transcription

1 DMA Core Reference Guide 32-Bit/64-bit AXI modes 1

2 CONTENTS 1 INTRODUCTION EXISTING HARDWARE MODULE COMPATIBILITY DIRECT MEMORY ACCESS CONTEXT OF A TYPICAL SOFTWARE DRIVER & IP CORE CORE OBJECTIVES PRODUCT OBJECTIVE SOFTWARE DRIVER TOP AMBA DMA CONTROLLER BLOCK DIAGRAM OVERVIEW DMA Controller TOP LEVEL AMBA DMA CONTROLLER PIN-OUT OVERVIEW CONTROL BLOCK (PART 1 OF THE TOP-LEVEL CORE) RX/TX BLOCK (PART 2 OF THE TOP-LEVEL CORE) THE TOP-LEVEL PIN-OUT OF THE DMA CONTROLLER HARDWARE DMA SPEED & THROUGH-PUT CAPABILITY INTRODUCTION ISOLATED DMA HARDWARE MODELING ISOLATED DMA REAL-WORLD CONSIDERATIONS SYNTHESIS OPTIONS GLOBAL SYNTHESIS OPTIONS RX DMA MECHANISM OVERVIEW RX DESCRIPTOR DEFINITIONS FLOW ILLUSTRATION OF RECEIVE RX ENGINE (LANDSCAPE VIEW) TX DMA MECHANISM OVERVIEW TX DESCRIPTOR DEFINITIONS FLOW ILLUSTRATION OF TRANSMIT TX DMA CORE (LANDSCAPE VIEW) FIFO INTERFACE BIT MAC/SWITCH INTERFACE DATA STRUCTURE BIT MAC/SWITCH INTERFACE DATA STRUCTURE FIFO INTERFACE TRANSMIT OPERATION FIFO INTERFACE RECEIVE OPERATION FIFO INTERFACE MODULO DEFINITION bit Usage bit Usage FRAME STATUS EXPANSION IO-REGISTER INTERFACE OVERVIEW REGISTER WRITE

3 12.3 REGISTER READ AHB-LITE TIMEOUT FOR EXTERNAL REGISTER ACCESS INTERRUPT CHANNELS OVERVIEW INTERRUPT SOURCES INPUT DESIGN ACKNOWLEDGEMENT OUTPUTS REGISTER INTERFACE (CONTROL BLOCK) OVERVIEW DMA CONTROLLER/STATUS REGISTERS TX_GLOBAL_CONTROL REGISTER TX_STATUS REGISTER RX_GLOBAL_CONTROL REGISTER RX_STATUS REGISTER ADDITIONAL INFORMATION REFERENCES CONTACT DOCUMENT HISTORY

4 Ab This Specification This specification introduces the MorethanIP AMBA DMA Controller top-level architecture, design and general information ab how a software driver would interface and operate the IP hardware Intended Audience This document is fully intended to be viewed and reference by MorethanIP/Nine Ways customers using the technology for larger designs and projects. 4

5 List of Figures Figure 1 - Context of the Linux Driver... 9 Figure 2 - Different scenarios of DMA Controller usage Figure 3 Top Model AMBA DMA Controller Schematic Figure 4 - AHB-Lite Bus Interface for the IO-Register component of the DMA Controller Top Module 14 Figure 5 AXI Bus Interface for the DMA Core component of the DMA Controller Top Module Figure 6 - Receive DMA Descriptor Entry Figure 7 - Flow Chart Diagram of the RX Receive DMA Engine Figure 8 - Transmit DMA Descriptor Entry Figure 9 - Flow Chart Diagram of the TX DMA Engine Figure 10: FIFO Transmit Interface Single Frame Figure 11: FIFO Transmit Interface - Frame Transfer with DMA Controller Pause Figure 12: FIFO Transmit Interface - Four Back-to-Back Frames Figure 13: FIFO Transmit Interface - Transfer with MAC/SWITCH Pause Figure 14: FIFO Transmit Interface - Errored Frame Figure 15: FIFO Receive Interface - Single Frame Transfer Figure 16: FIFO Receive Interface - Transfer with DMA Controller Pause Figure 17: FIFO Receive Interface Frame with Errors Figure 18: Register Write Timing Diagram Figure 19: Register Read Timing Diagram Figure 20: External IRQ Acknowledgement Timing Diagram

6 List of Tables Table 1: AMBA DMA Controller Pin- Description Table 2: Isolated DMA capabilities also expressed as data rate in Gbit/s for bus frequencies Table 3: Synthesis Package Definitions (mtip_dma_pack_package.verilog) Table 4: Receive Descriptor Definition Table 5: Transmit Descriptor Definition Table 6: 32-bit FIFO Interface Data Structure Table 7: 64-bit FIFO Interface Data Structure Table 8: Transmit/Receive 32-bit FIFO Interface word Modulo Definition Table 9: Transmit/Receive 64-bit FIFO Interface word Modulo Definition Table 10: Frame Status Word Bits Table 11: Global Register Map (Control Block) Table 12: Interrupt Sources Table 13: Global Register Map (Control Block) Table 14: IO-Register Map Table 15: TX_GLOBAL_CONTROL Register (Offset 0x00) Table 16: TX_STATUS Register (Offset 0x04) Table 17: RX_GLOBAL_CONTROL Register (Offset 0x100) Table 18: RX_STATUS Register (Offset 0x104) Table 19: Contact Information Table 20: Document History Entry Log

7 1 Introduction This document lines and covers all aspects of the AMBA DMA Controller IP Core hardware that facilitates a method of enabling high speed bandwidth in both directions from an Ethernet pathway to a CPU sub-system. The emphasis is to allow Ethernet frames to/from a MAC/SWITCH into the CPU sub-system using hardware in the form of an AXI master. Application programmers particularly those who are increasingly benefitting from being able to port powerful data processing software into an embedded environment are increasingly looking for an ability to process huge exposure to network traffic on target platforms. This is in stark contrast to previously only having the processing ability to observe or manage data network traffic on behalf of other systems because of the bottleneck and restrictions of software layers associated with network hardware including master DMA blocks as part of a wider processor system. The primary objective of such a solution confidently provides a rare ability to exceed the traditional boundaries of fast Ethernet 100Mbit/s throughput full duplex with application software running on offthe-shelf affordable target devices. This is achieved by the pioneering architecture of MorethanIP design technology with DMA (Direct Memory Access) in the fabric of a silicon device. Any software device driver needed would be minimal in processor execution overhead; the constraints and responsibility are placed upon the application programs instead. The hardware is designed to perform as much processing of the data transfer as possible with only the setup and completion work to be carried between any software driver and the DMA hardware IP core. The DMA controller is also very flexible in its footprint and capabilities in terms of how it can interface and support different data widths, bus types, silicon device vendors, packet priority behavior, and the way the data is interpreted from physical memory. The deliverable package provides full Verilog source, simulation, synthesis, optional device driver (with source code) depending on customer requirements, documentation and scripts. All of these will be discuss later in the document. 1.1 Existing Hardware Module Compatibility Currently, there are many different network IP cores and modules for FPGA and ASIC silicon devices. These cores vary in terms of the position they fit into building a network controller system or high-end Ethernet switch fabric. Usually, the boundary of logic core deliverable is the application side of the MAC or an Ethernet switch which always presents a generic FIFO interface. It is this standardization of a powerful interface from a FIFO buffer that connects to the DMA IP core module with the host processor bus technology on the other side. With the processor and the FPGA fabric together, the common standard bus mechanism is AXI and/or AHB-Lite is required to allow both to communicate. As will be seen later on in this documentation, the DMA Controller IP will comfortably position between a vendor s processor environment and all the current MorethanIP IP cores with a FIFO interface. Traditionally, the FIFO interface would have been accessed via slave DMA modules via PCI Express or AXI buses from the processor and would have required exhaustive processor execution or at best, costly DMA setup per transaction. Now, with this new DMA Controller master, many packets will pass either way full duplex exerting only minimal interrupt IRQ house-keeping on the packet memory transactions. Moreover, multi-packet setup using descriptor tables keeps the processing execution even lower within the kernel device driver leaving the majority share of processor execution time to the operating system and application software. 7

8 1.2 Direct Memory Access AMBA DMA Controller (with AXI memory interface) DMA has been around for a long time and more and more solutions are looking for hardware to process data in order to allow critical resources to be freed up. This product has been developed as high speed DMA solution to allow Ethernet network traffic destined for a device to be exposed to application software processing physical memory content. The main emphasis is exposing the packets in memory visible to application code to the network as efficiently as possible. This will not invoke huge processing resources beyond what the application is performing, thus the customer program is not be aware of the mechanism on how the hardware that is controlled by the software device driver will be performing. The solution uses advanced DMA in the fabric driving the memory bus of a given system environment. Therefore, simple application interfacing to the surrounding IP network has been achieved with forcing the end user to have to utilize non-standard distributions of software and more importantly, all of the logical hardware can reside in the same target device. 8

9 2 Context of a typical Software driver & IP core Important Note: This chapter is an example environment illustrating a device driver under Linux. This can be provided by MorethanIP/Nine Ways, but for this document, only serves as an example. Any software platform can be used to interface to the DMA IP hardware. The controlling software driver needed to initialize and handle the RX and TX Ethernet frames through the DMA Controller IP hardware, can be written in any language, in any operation system environment, or even bare-metal situations where the driver functionality controlling the DMA occupies near full execution of the CPU. However, most commonly, users prefer the C-language, and more commonly they do like to choose a good well established OS and that a device driver is therefore needed. MorethanIP/Nine Ways do provide a pre-supplied flavor of device driver for an OS, but this is detailed in other documents. For now, we will concentrate on the generic functionality and concept of the DMA Controller. Below is an illustration of a typical driver, its surrounding environment, and the interface to the hardware module blocks. For the purpose of the illustration shown, it indicates how it would typically fit into a Linux environment for example: Figure 1 - Context of the Linux Driver The Linux device driver and its associated hardware DMA Controller are highlighted in dashed red. They only form a small part of the overall infrastructure that will integrate to provide an overall solution for an application. The hardware DMA Controller is represented by the thick red arrow and is only concerned with reading and writing Ethernet packet frames into a buffer in the processor subsystem memory. Multiple 9

10 packets can be fetched and transmitted to/from the DMA controller to the MAC/SWTICH FIFO forming a transmit TX packet and data can be written to the RAM constituting a receive RX. A black arrow is shown from the memory linking the IP stack with the application API. This shows how the memory allocation in RAM is constant for all of those. The DMA device driver, the IP stack and application software in the layers above only pass on and process the pointer location to the frame buffer in working RAM. In its most ideal operation, the only transfer of data is performed by the DMA Controller IP in and of the DDR memory, and then the Linux kernel transfers a pointer around the entire software OSI layer. If the packet then replies from the application layer API with just modified data contents performed by the intended algorithm of its usage, then essentially the DMA Controller moves packets into RAM, they are processed by high-level software and then DMA transferred back to the MAC forming a read-process-write mechanism. (Note: this is only achievable with careful management of memory buffers and full control of the IP stack with regards to minimum CPU-copy). Figure 2 - Different scenarios of DMA Controller usage The Figure (above) illustrates the typical IP cores that may be requested by a system designer that is to be an integrated design inside a target device such as an FPGA. The Linux device driver that is provided only handles and interacts primarily with this DMA Controller which is common to all of the examples in the illustration. 10

11 3 Core Objectives AMBA DMA Controller (with AXI memory interface) The DMA Controller implements the following functionalities: 1. Flexible DMA controller to attach MorethanIP FIFO interfaces to system busses such as AMBA AXI. 2. Support flexible bus width of 32-bit and 64-bit system memory busses. 3. Support flexible FIFO data-width of 32-bit and 64-bit to the hardware. 4. At minimum supporting two independent channels (descriptor rings), one for ingress (FIFO to bus) and one for egress (bus to FIFO) data transfers. a. Scalability to support more than 1 descriptor ring per direction (e.g. to allow multiple rings for traffic of different priority) 5. Three Independent AMBA Interfaces a. AHB-Lite Control Block to allow internal and external register access for control and configuration of the DMA controller as well as provide access to registers within the externally connected module (MAC, Switch configuration etc) b. AXI Write Master (TX) to transfer data from memory to FIFO interface. c. AXI Read Master (RX) to transfer data from FIFO interface to memory. 6. Fully independent (parallel) operation of Egress (TX) and Ingress (RX) channels. 7. Up to 128-bit of control and status (side-band) in formation transferred transparently with frames for arbitrary use by system and application (e.g. timestamps carrying PTP-1588 L2 frames) 8. Flexible interrupt support for efficient transmit and receive handshaking. 9. Pass-through ability to SWITCH/MAC for hardware calculation of UDP/TCP header checksum removing CPU processor burden per packet. 10. IO-Register control/status with MUX providing throughput access to cascaded hardware cores. 3.1 Product Objective The DMA Controller core exists as an encapsulated modular design that is device vendor independent and will modularly connect to the user interface that being the FIFO interface of a MAC/SWITCH. The other side of the data transfer from the FIFO is a memory bus interface complying with the AMBA standard for AXI. Essentially, the is a hardware efficient method of interchanging the FIFO Ethernet frame traffic from other IP Ethernet cores to a common memory bus so that useful user application software can run in order to process the data in the real world. This can only be achieved by providing the user applications a realistic chance of ever being able to process such large amounts of Ethernet packets in either direction. By using a software device driver to allow a program to run it will now be able to facilitate far more of a complete solution to the user than just a generic FIFO (client) interface from a MAC/SWITCH core. 11

12 It is most important to conclude (for this introduction) that this DMA Controller hardware provides the ability for a user to use a single silicon device to process as an end-point to the Ethernet traffic at ~100Mbit and above (not just as a burst but as sustained average consumption). Most commonly, other IP cores have allowed very high speed Ethernet passing through the devices but not as part of a solution to consume and process that data as something useful. 3.2 Software Driver Whilst it is not assumed or compulsory to have to use a Linux driver, one has been provided as a start point for users. Any driver can be written and customized to users needs, but most commonly a Linux based environment is chosen by system designers. Any software driver s objective is to manage the DMA Controller hardware and potentially initialize all MorethanIP associated hardware alongside (MAC, PHY, PCS and SWITCH). The uclinux device driver that is provided with the DMA Controller, as standard provides the C files to compile the basic device driver only. Other packages on other Nine Ways products such as NetFusion, include PTP-1588 and a customized iperf feature. However, this document relates only to the AMBQ DMA Controller as a deliverable stand-alone package. 12

13 4 Top AMBA DMA Controller Block Diagram 4.1 Overview Below illustrates the Top-Level DMA core. Within the core it shows a Control Block next to an RX/TX DMA Engine. The RX/TX engine handles all RX and TX DMA transfers between AXI memory bus and the FIFO bus. The Control Block handles the AHB-Lite IO-Registers, IRQs and general control of the RX/TX block. Figure 3 Top Model AMBA DMA Controller Schematic DMA Controller The DMA Controller Core is divided into two main functional blocks: 1. Control Block: Implements an AHB-Lite Slave interface to allow access to internal and external registers for management and status. 2. Combined Read/Write AXI Master (RX/TX): Transfers data from FIFO receive interface into system memory (write) and independently transfers data from system memory (read) to FIFO transmit interface. The Control Block DMA IO-Registers allows memory mapped control and status of the DMA Controller core. Additionally, it provides a throughput via a MUX to other addressable hardware cores such as MACs, PCSs and SWITCHs. This provides the processor sub-system a simple mapped DMA primary interface which then delegates the addressing in a cascaded fashion to additional hardware cores that are typically associated with this controller when considering the design. 13

14 5 Top Level AMBA DMA Controller Pin- 5.1 Overview The overall DMA Controller deliverable will be synthesized with the following memory bus mechanisms; 1. AHB -Lite 2. AXI (Specifically AXI-4) The AXI is a fast streaming bus that will cope with the flow of RX and TX bursts from the DMA Master AXI interfaces. This is the main bus mechanism for the transferred data. However, the IO-Register access for read/write control and feedback is mapped on an AHB-Lite bus. All silicon device architecture now uses some form of AHB-Lite bus system. Important Note: The figure in the previous section shows the blocks in the Top Level DMA core. Within the core it shows a Control Block next to an RX/TX DMA Engine. The RX/TX engine handles all RX and TX DMA transfers between AXI memory bus and the FIFO bus. The Control Block handles the AHB-Lite IO-Registers, IRQs and general control of the RX/TX block. For the purpose of neatness and clarity, those two separate blocks with-in the top-level core, are separately shown below. In effect, both combine to form the overall pin- but are just shown separately. 5.2 Control Block (Part 1 of the Top-Level Core) Figure 4 - AHB-Lite Bus Interface for the IO-Register component of the DMA Controller Top Module 14

15 5.3 RX/TX Block (Part 2 of the Top-Level Core) Figure 5 AXI Bus Interface for the DMA Core component of the DMA Controller Top Module 15

16 6 The Top-Level Pin- of the DMA Controller Hardware Table 1: AMBA DMA Controller Pin- Description Signal Name Mode Description reset_clk_ahb hclk reset_clk_axi aclk in in in in Active high reset signal for clk clock domain. Reset the logic synchronized by the clock hclk. (ahb_aresetn AHB-Lite AMBA bus system reset). This pin is tied to the ahb_aresetn of the main ARM AMBA bus. Note: As this is active HIGH, a negative clock source will require inversion. System Clock (AHB-Lite AMBA bus system clk). Note: This can be tied together with aclk if the system shares a common clk. Active high reset signal for clk clock domain. Reset the logic synchronized by the clock aclk (axi_resetn - AXI AMBA bus system reset). This pin is tied to axi_resetn of the main ARM AMBA bus. Note: As this is active HIGH, a negative clock source will require inversion. System Clock. System Clock (AXI AMBA bus system clk). Note: This can be tied together with hclk if the system shares a common clk. AXI Bus Write Signals (synchronized to the AXI clk) awid[axi_id_width- 1:0] Write address ID. This signal is the identification tag for the wriet address group of signals. awlen[3:0] Burst length. The burst length gives the exact number of transfers in a burst. awsize[2:0] Burst size. This signal indicates the size of each transfer in gthe burst. awburst[1:0] awaddr[amba_addr_ WIDTH-1:0] awcache[3:0] awprot[2:0] awvalid awlock[1:0] wdata[amba_data_ WIDTH-1:0] wstrb[amba_data_ WIDTH/8-1:0] Burst type. The burst type, coupled with the size of the information, details how the address for each transfer within the burst is calculated. AXI write address. The write address bus gives the address of the first transfer in a write burst transaction. Cache type. This signal indicates the buffer, cache, write-through, write-back, and allocate attributes of the transaction. Protection type. This signal indicates the normal, priviledged, or secure protection level of the write transaction and whether the transaction is a data access or an instruction access. The default value is normal, non-secure, data acess. Default: 2 Write address valid. This signal indicates that valid write address and control information are available. Lock type. This signal provides the additional information ab the atomic characteristics of the transfer. Default: normal Write data bus. Write strobes. This signal indicates which byte lanes to update in physical DDR memory. wlast Write last. This signal indicates the last transfer of a burst transaction. 16

17 wvalid Write valid. This signal indicates that valid write data and strobes are available. awready in Write address ready. This signal indicates that the slave is ready to accept an address and associated control signals. wready in Write ready. This signal indicates that the slave can accept the write data. bid[amba_data_ WIDTH-1:0] in Response ID. This is the identification tag for the write response signals. bresp[1:0] in Write response. This indicates the status of the write transaction. bvalid in Write response valid. This signal indicates that a valid write response is available. AXI Bus Read Signals (synchronized to the AXI clk) bready arid[axi_id_width-1:0] araddr[amba_addr_ WIDTH-1:0] arprot[2:0] arcache[3:0] arvalid Response ready. This signal indicates that the master can accept the response information. Read address ID. This signal is the identification tag for the read address group of signals. Read address. The read address bus gives the initial address of a read burst transaction. Protection type. This signal provides protection unit information for the read transactions. The default value is normal, non-secure, data acess. Default: 2 Cache type. This signal provides additional information ab the cache characteristics of the transfer. Read address valid. When HIGH, this signal indicates that the read address and control information are valid. The signal remains stable until the address acknowledgement signal, M_AXI_ARREADY, is HIGH. arlen[3:0] Burst length. The burst length gives the exact number of transfers in a burst. arsize[2:0] Burst size. This signal indicates the size of each transfer in the burst. arburst[1:0] arlock[1:0] rready rmw arready in Burst type. The burst type, coupled with the size of the information, determines how the address for each transfer within the burst is calculated. Lock type. This signal provides the additional information ab the atomic characteristics of the transfer. Default: normal Read ready. This signal indicates that the master can accept the read data and response information. Read-Modify-Write. This is controlled by a register bit and signals to a host processor environment such as the ARM sub-system the policy of whether to enable RMW. This is normally just a configuration setting for the sub-system which varies depending on the vendor. This is set in software. Read address only.this indicates that the slave is ready to accept an address and associated control signals. rid[axi_id_width-1:0] in Read ID tag. This is the identification tag for the read data group of signals. rdata[amba_data_ WIDTH-1:0] in Read data bus. rresp[1:0] in Read response. This signal indicates the status of the read transfer. rvalid in Read valid. This signal indicates the last transfer in a read burst. rlast in Read last. This indicates the last transfer in a read burst. 17

18 RX FIFO Interface (MAC or SWITCH) (synchronized to the AXI clk) ff_rx_err_stat[4:0] ff_rx_data[c_fifo_dat A_WIDTH-1:0] ff_rx_sop ff_rx_eop ff_rx_err ff_rx_mod[2:0] ff_rx_xstat[127:0] ff_rx_dval ff_rx_dsav ff_rx_protocol_checksu m[15:0] ff_rx_protocol_checksu m_valid ff_rx_ch in in in in in in in in in in in in Receive Frame Status and Error indications from MAC/SWITCH. A status word is available with each received frame with the final octet (ff_rx_eop set to 1 ). bit 0: bit 1: bit 2: bit 3: bit 4: Current Frame invalid length Current Frame CRC-32 error Frame was truncated due to FIFO RX overflow PHY signal error (gmii_rx_err from PHY to MAC/SWITCH) Current frame implements VLAN tag Note: Any additional bits such as VLAN Payload Length and Collision detection will have to be placed into the xstat extended bits as per project design required by a customer. Received Data. The first bytes received is ff_rx_data[7:0] and upwards... Received Start of Packet. Set to 1 when the first octet of a frame is driven on ff_rx_data[7:0]. Received End of Packet. Set to 1 when the last word of a frame is driven on ff_rx_data[31:0] or ff_rx_data[63:0] depending on bus width selected. Received Frame Error. Asserted with the frame final word to indicate that an error was detected by the MAC/SWITCH when receiving the frame. Error code is described and presented on lines ff_rx_err_stat[4:0] Received Data Modulo. This indicates which portion of the final frame word is valid. There are 3 bits here as it supports the inclusion of utilizing 64-bit data bus widths. Note: See Tables further documented for bit-meanings and descriptions for 32-bit and 64-bit variants. Received Extra Status Vector information. A 128-bit side-band data block presented from the MAC/SWITCH on the last word received from the FIFO interface. Received Data Valid. Asserted to 1 by the MAC/SWITCH to indicate that data on ff_rx_data[c_fifo_data_width-1:0], ff_rx_sop, ff_rx_eop, ff_rx_err and ff_rx_err_stat[4:0] are valid. Receive Frame Data Available Indicator. Indication that the receive FIFO of the MAC/SWITCH contanis data to be read (not necessarily the complete frame at that point in time). The DMA RX Controller could start to read the FIFO if desired. This receives the UDP/TCP checksum range data to be stored in the RX Descriptor entries for each frame. This stores the 16-bit byte-swapped result back in to the descriptor entry for application use. Note: This data is presented from the MAC/SWITCH on the last word received from the FIFO interface. If set to 1, the ff_rx_protocol_checksum[15:0] signal is driven with the UDP/TCP checksum data from the MAC/SWITCH as the functionality is therefore supported.. Note: signal is valid from ff_tx_sop through ff_tx_eop.this is acheived as a MAC/SWITCH has FIFO buffers to store and hold tha packet frame to analyse. This indicates which Descriptor channel the received RX packet frame should go to. If asserted to 1 then it indicates that the frame should go to CH1 otherwise if kept LOW then CH0. If it is asserted then it must be stable when ff_rx_sop is set. It must remain stable until ff_rx_eop is set. It should already be valid and stable when ff_rx_dsav asserts, hence the RX DMA scheduler can prepeare the correct DMA RX channel to read. 18

19 ff_rx_ready Receive Application Ready. Set to 1 by DMA RX Contoller to indicate that it is ready to receive data from the MAC/SWITCH. ff_rx_ready must be generated on clk rising edge. TX FIFO Interface (MAC or SWITCH) (synchronized to the AXI clk) ff_tx_ready ff_tx_dsav ff_tx_data[c_fifo_dat A_WIDTH-1:0] ff_tx_sop ff_tx_eop ff_tx_dval ff_tx_mod[2:0] ff_tx_xstat[127:0] ff_tx_err ff_tx_crc_fwd ff_tx_protocol_checksum _enable ff_tx_protocol_checksum [31:0] in MAC/SWITCH hardware FIFO is ready for transmission when set to 1. Only when there are more than 2 entries free in a given channel descriptor table, will this signal be de-asserted and set to 0. Note: The TX DMA should stop writing to the interface with in one clock cycle (1 cycle latency) Note: five entries gives the fast FIFO activity time to react with loosing packets when no free entries are available. Transmit Data Available Indicator. Set to 1 when the DMA TX Controller is ready to transmit to MAC/SWITCH because it has data to send. Transmit Data. The first bytes received is ff_tx_data[7:0] and upwards... Transmit Start of Packet. Set to 1 when the first octet of the frame is driven on ff_tx_data[7:0]. Transmit End of Packet. Se to 1 when the final word of a frame is driven on ff_tx_data[31:0] or ff_tx_data[63:0] depending on bus width selected. Transmit Data Valid. Asserted to 1 by this DMA TX Controller to indicate that data on ff_tx_data[c_fifo_data_width-1:0], ff_tx_sop, ff_tx_eop and ff_tx_err are valid. Transmit Data Modulo. This indicates which portion of the final frame word is valid. There are 3 bits here as it supports the inclusion of utilizing 64-bit data bus widths. Note: See Tables further documented for bit-meanings and descriptions for 32- bit and 64-bit variants. Transmit Extra Status Vector information. A 128-bit side-band data block presented to the MAC/SWITCH on the first octet transmitted to the FIFO interface. Note: This is in contrast to the receive xstat function. For TX, the xstat information must be available and present at the beginnig of the packet frame. There could be certain important bits of information that the MAC/SWITCH needs to know before handling the frame. With RX, it is only presented at the end of the packet frame ff_rx_eop before being stored in the RX descriptor entry. Transmit Frame Error. Set to 1 with the frame final word to indicate that the transmitted frame is invalid. TX MAC/SWITCH CRC forward from the software device driver. If set to 0 together with ff_tx_eop, a CRC is calculated and appended to the frame in the MAC/SWITCH core. If set to 1, the MAC/SWITCH does not append a FCS to the frame. Instead the frame is transmitted unchanged. ie/ The CRC is forwarded from the software device driver. If set to 1, the ff_tx_protocol_checksum[31:0] signal is driven with the UDP/TCP checksum data so that the MAC/SWITCH (if supporting this functionality) can hardware calculate the TCP/IP or UDP/IP protocol header/payload chechsum and insert into the TCP/IP or UDP/IP header. Note: Must be valid from ff_tx_sop through ff_tx_eop. If ff_tx_protocol_checksum_enable is asserted, this transmits the UDP/TCP checksum range data stored in the TX Descriptor entries for each frame. This is used to calculate the start and size of the UDP/TCP protocol arithmatic in the Ethernet frame and also where to store the 16-bit byte-swapped result. Assert this bus before ff_tx_sop active. Note: Must be valid from ff_tx_sop through ff_tx_eop. 19

20 ff_tx_ch This indicates which Descriptor channel the transmitted TX packet frame originated from. If asserted to 1 then it indicates that the frame came from CH1 otherwise if kept LOW then CH0. If it is asserted then it must be stable when ff_rx_sop is set. It must remain stable until ff_rx_eop is set. Note: This can be used as a priority system for the tranportation mechanism. AHB-Lite Control Block Interface (synchronized to the AHB clk) haddr[31:0] in The 32-bit address bus. hburst[2:0] hmaster_lock hprot[3:0] hready hsel in in in in in These signals indicate if the transfer forms part of a burst. Four, eight, and sixteen beat bursts are supported and the burst can be either incrementing or wrapping. Indicates that the current master is performing a locked sequence of transfers. This signal has the same timing as the HMASTER signals. The protection control signals provide additional information ab a bus access and are primarily intended for use by any module that requires some level of protection. The signals indicate if the transfer is an op-code fetch or data access, as well as if the transfer is a privileged mode access or User mode access. For bus masters with a memory management unit these signals also indicate whether the current access is cacheable or buffer capable. When HIGH, the HREADY signal indicates that a transfer has finished on the bus. You can drive this signal LOW to extend a transfer. Each AHB slave has its own slave select signal and this signal indicates that the current transfer is intended for the selected slave. This signal is simply a combinatorial decode of the address bus. hsize[1:0] htrans[1:0] hwdata [31:0] hwrite hrdata[31:0] hresp[1:0] hready_ in in in in These signals indicate the size of the transfer, typically byte (8-bit), half-word (16- bit), or word (32-bit). The protocol permits larger transfer sizes up to a maximum of 1024 bits. This indicates the type of the current transfer. This can be NONSEQUENTIAL, SEQUENTIAL, IDLE, or BUSY. The write data bus transfers data from the master to the bus slaves during write operations. ARM recommends a minimum data bus width of 32-bits. However, you can easily extend this to enable higher bandwidth operation. When HIGH, this signal indicates a write transfer, and when LOW, a read transfer. The read data bus transfers data from bus slaves to the bus master during read operations. ARM recommends a minimum data bus width of 32-bits. However, you can easily extend this to enable higher bandwidth operation. The transfer response provides additional information on the status of a transfer. Four different responses are provided, OKAY, ERROR, RETRY, and SPLIT. Transfer Done. The AHB slave uses this signal to extend an AHB transfer. Default state: 1 External Register bus (synchronized to the AHB clk) ext_reg_busy ext_reg_interrupts[15:0] ext_reg_intack[15:0] in in Register interface busy signal. Assert 1 during register read or write access. Set to 0 to indicate the completion of the current register access. 16 external interrupt lines from general purpose cascaded hardware cores such as MACs and SWITCHs. These are level sensitive and are standardized to forward an interrupt on a positive 1 assertion when the logic is clocked. Acknowledge strobe for each of the 16 external interrupt lines respectively ext_reg_interrupts [15:0]. These lines strobe positively for one clock cycle then restore back to 0 to clear a pending interrupt generated externally. The INTERRUPT_PENDING register drives this operation when the user application or Linux device driver software clears the corresponding pending flags. 20

21 ext_reg_rd ext_reg_wr Register interface READ control signal (Register Read Enable). Assert 1 during register read access. Set to 0 when not attempting a register read. Register interface WRITE control signal (Register Write Enable). Assert 1 during register write access. Set to 0 when not attempting a register write. ext_reg_addr[19:0] Register Address bus. Bit 0 is the least significant bit. ext_reg_ wdata[31:0] Register Write Data bus. Bit 0 is the least significant bit. cpu_int ext_resetn Connects to the CPU sub-system usually the ARM for embedded applications in device silicon The internal reset_clk line from the AMBA bus is forwarded to this pin to be tied to other cores e.g. MAC or SWITCH. As the IO-Register Interface is compulsory with the DMA RX/TX core, and that this block handles the forwarding of configuration IO Registers it therefore has this active LOW reset line derived from the AHB-Lite bus system. This allows further logic hardware to be synchronized reset with the main system. 21

22 7 DMA Speed & Through-put Capability 7.1 Introduction The most important section in this manual is probably this one. You will probably want to know what performance this DMA hardware IP core will enable you to have! It is always very ambiguous when expressing such performance capabilities as the environment that this DMA product shall be running is never the same and is affected by software, memory bus contention, bus system clock speed and other caching architecture. It also has to be understood that what clocking capabilities the DMA hardware core can achieve in isolation is a perfect environment and is going to be much higher performance and throughput than any real-world environment whether low-end platforms or high-end. Nevertheless, for comparative reasons, this section will state the isolated throughput tests and capability separate to the platform bench-tests. Also, the platform measurements are only a start point at this time, which the DMA hardware has been established working and that beyond the initial release of the product, more target devices, supporting hardware and higher clocking speeds can be utilized. 7.2 Isolated DMA Hardware Modeling For each and every RX or TX Ethernet frame to the DMA Controller: 1. There are 3 clock cycles of overhead in the IO-Register layers (this does not apply to the RX DMA process) 2. Followed by 2 clock cycles overhead for the AXI initial addressing 3. Per FIFO transaction to the MAC/SWITCH (this can be 32-bit or 64-bit) there are 2 clock cycles. 4. Per setup of AXI burst sequences, there are usually no additional clock cycles on good AXI models. This is because the address bus setup and confirmation can be achieved simultaneously with previous data burst transactions. This assumption will be used for this section. 5. A single clock cycle for the AXI completion 6. Finally, 2 clock cycles for IO-Register updating and re-synchronization before next frame can be handled by the DMA TX block. For isolation tests and performance, it is ideal criteria that we are trading with maximum size (MTU) Ethernet Frames of 1518 octets (plus overhead from the MAC layer). However, the results below will show the variation with some different sized Ethernet frames. Please Note: This is the whole frame including MAC header, IP, and all IP payload and protocols but NOT the CRC at the end or preamble at the start of a frame. Additional Note: the reduction in the 3 clock cycles for setup with the RX will be ignored for the following tables of results as this will make negligible difference to the noticeable rate. It will assume that the RX does induce 3 clocks just like the TX DMA at the start of each frame. This simplifies the results to view. 22

23 Table 2: Isolated DMA capabilities also expressed as data rate in Gbit/s for bus frequencies MTU Data Width 32-bit 64-bit 32-bit 64-bit 32-bit 64-bit Total Clock Cycles Bus Frequency MHz Bus Frequency 41.5 MHz Bus Frequency 83 MHz Bus Frequency 166 MHz Bus Frequency 333 MHz Data Rates expressed in Gbit/s Note: An assumption that a CRC has been included and added on to the MTU size. Preamble will have been stripped by the MAC/SWITCH. Additional Note: An assumption has been made that once a frame has completed, another one starts immediately and there is no gaps in between the DMA processes from the end of IO-Register updates for the previous frame and the setup process for the next frame. 23

24 7.3 Isolated DMA Real-World Considerations The clocking table (above previously) illustrates a very simplistic measurement with wild assumptions. However, if comparing the effectiveness and efficiency of other DMA mechanisms, then this information may prove indispensable for selecting the best solution to your design. Below are several important realistic considerations to take into account when seeing differences between real-world platform measurements against the isolated (test-bench ModelSIM) DMA Controller: 1. The processor sub-system could not ever cope with constant data saturation at maximum bus frequency. The cached instructions would need to access memory. 2. The application code would need to process the information taking up more execution time, clock frequency and creating bus contention. 3. The AXI bus would not necessarily provide an acknowledgement for address and data read/write transactions after the minimum 2 clock cycles. 4. The MAC/SWITCH connected beyond the FIFO interface could be a bottleneck restriction. 5. MTU packet sizes will vary and not always utilize the maximum efficient size. 6. The processor has to take time to access the RX and TX descriptor tables using the memory bus. 7. Other peripheral hardware will more than likely share the same memory bus architecture. This will cause contention that will be observed by the DMA AXI Master hardware as long delays waiting for an initial acknowledgement to the first address request of a given Ethernet frame or even per AXI read/write burst chunk. 8. The IP stack of any system chosen will always even with minimal CPU-copy techniques, inevitably bottleneck the data flow. 9. AXI times on hardware glitches and possible contention errors will introduce an average drop in throughput. 10. Pipelining of AXI host hardware will introduce delays for each Ethernet frame. Pipelining will attempt to keep the consecutive AXI read/write bursts flowing with the address request far ahead of the data equivalent burst. However, initial setup per frame and occasional times and contention on the AXI bridges and the DDR controller will affect the response time. 11. Ultimately, the nature of the memory storage will also bottleneck the independence of the RX TX pathways through the DMA Controller. If the DDR interface to the SDRAM device is half duplex, which can occur in LPDDR devices, and then this shall cause contention across the RX and TX pathways. Only full-duplex DDR interfaces keep ideal separation. 24

25 8 Synthesis Options 8.1 Global Synthesis Options AMBA DMA Controller (with AXI memory interface) The following table lists the relevant synthesis options found in the global package file. This file is included by all sources to set global definitions. These are for size optimizations and to include/exclude features that affect pin-s of modules. The file is included by every relevant source file to configure several options during synthesis. The following settings in this file can be changed. All others must remain unchanged. Table 3: Synthesis Package Definitions (mtip_dma_pack_package.verilog) Setting Name Type Description Default Revision Configuration MTIP_CUSTOMER_ SPECIFIC_REVISION parameter MTIP_CORE_VERSION parameter DO NOT CHANGE This can be any 16-bit integer value. It is stated in hexadecimal in the package file and is used as a sub-version number by a project integrator using this DMA Controller package in their design (HEX) 1301 (HEX) Data Width & AXI Master Configuration AMBA_ADDR_WIDTH parameter Global AMBA system data width. This affects the AXI address width only in this case. It sets the number of bit of the AXI Master address bus and MUST match the width of the system memory bus of the host device system architecture. MTIP_MAC_UUT_64BIT `define Note: Must be a power of 2, at least 32. This define states whether the DMA system data width is 64-bit or not. By `defining it declares the parameter AMBA_DATA_WIDTH to be 64. Else, it allows parameter AMBA_DATA_WIDTH to be 32. This parameter governs the width of the FIFO data interface and the AXI Master data width for both RX and TX pathways. The parameter AMBA_DATA_WIDTH is controlled by a `define because of a ModelSIM Testbench requirement. Note: The width of the DMA system data width (AXI and FIFO) is restricted to 32 or 64 only. Other attempted values will cause problems with operation. 32 Defined 25

26 AXI_ID_WIDTH AXI_RXDMA_ BACKPRESSURE_SIZE parameter parameter Sets the number of bits for the write AXI address ID, write AXI data ID, read AXI address ID and read AXI data ID (rid). This width is variable and you can use this to match the size of the AXI Slave that the DMA Controller Master connects to. Note: Usual values are 2, 3 or 4. Depth of the RX-DMA backpressure FIFO. This FIFO cushions the initial [sop] data to activate the RX mechanism, and also allows for the MAC to react slowly to an RX-DMA ready signal de-assertion. This, if set too low (less than 4 can cause problems with the RX if the ready signal is dropped to the MAC). Note: This can be set as high as 2048 but optimally is operates well at 16 or 32. RX & TX Descriptor Table Configuration 4 32 RXCH0_DESCSIZE parameter Sets the size of the High priority RX-DMA (Channel 0) descriptor table size in terms of entries. This value if <zero> effectively disables the RX-DMA CH0 mechanism. Maximum allowed value is 256. Note: Values in the higher range provide for better burst and high throughput performance, but may not synthesize well in smaller device families. RXCH1_DESCSIZE parameter Sets the size of the Low priority RX-DMA (Channel 1) descriptor table size in terms of entries. TXCH0_DESCSIZE parameter This value if <zero> effectively disables the RX-DMA CH1 mechanism. Maximum allowed value is 256. Note: Values in the higher range provide for better burst and high throughput performance, but may not synthesize well in smaller device families. Sets the size of the High priority TX-DMA (Channel 0) descriptor table size in terms of entries. This value if <zero> effectively disables the TX-DMA CH0 mechanism. Maximum allowed value is 256. Note: Values in the higher range provide for better burst and high throughput performance, but may not synthesize well in smaller device families

27 TXCH1_DESCSIZE AMBA DMA Controller (with AXI memory interface) parameter Sets the size of the Low priority TX-DMA (Channel 1) descriptor table size in terms of entries. This value if <zero> effectively disables the TX-DMA CH1 mechanism. Maximum allowed value is 256. Note: Values in the higher range provide for better burst and high throughput performance, but may not synthesize well in smaller device families. Other Settings All other settings must be left unchanged. N/A 4 Special Consideration: 1. The Number of DMA channels is fixed at two TX channels additional to two RX channels. This allows for a priority of CH0 TX and CH0 RX over CH1 TX and CH1 RX for Ethernet frame prioritization. 2. The AXI and the AHB-Lite (Control Block IO-Registers) AMBA bus interface is little-endian. The FIFO Interface is always little-endian (bit7:0 is first byte, bit31:24 is last byte of a 32-bit word). 3. The Number of Descriptors per RX/TX channel for CH0 and CH1 are independently definable and configurable by synthesis parameters. The default value for each exists from reset until the device driver issues a configuration change before enabling the DMA engines. 4. The Descriptor Size is fixed to six words. 5. CH0 of both RX and the TX independent full-duplex pathways take priority over the CH1 descriptor entries for each respectively. For TX: The DMA engine will always search the CH0 first before CH1. For RX: The software device driver should transact CH0 receive entries before assessing the CH1 entries. 6. AHB-Lite Data Width (for Register-IO Control Block) = 32-bit. Note: The AHB address width is limited to 32-bit. However, the AHB-Lite bus is only utilized from the host system for the access to the IO-Registers as this bus is just for register read/write control. 27

28 9 RX DMA Mechanism 9.1 Overview AMBA DMA Controller (with AXI memory interface) The system software (device driver) initializes two descriptor rings in IO-Register space. Each ring is AHB-Lite IO-Register space which holds the descriptors one after each other. For each ring a read and write pointer register exists in the controller hardware. These pointers are used by the hardware to determine if there is space available in memory to receive data. The pointer is a simple number giving the position of the descriptor within the descriptor ring (i.e. it is not the real address). When data is available at the FIFO interface, the current descriptor data provides all necessary information for the DMA engine to know where to write the data to (address) and how many words it can store in such buffer. When the DMA has completed processing the data, a status word is generated and will update the status word (word0 of the descriptor) in the IO-Registers. A done indication is given back to the descriptor selection function, which will start another transaction as needed. 9.2 RX Descriptor The descriptors are held in an IO-Register space in the hardware. The hardware accesses them in order implementing a ring-buffer. The size of the buffer (i.e. number of descriptors) is defined in hardware by parameterized options and limited to a maximum of 256 descriptors entries. The descriptors are initialized by the software device driver. When the transaction is completed it will write the information into the table entry including also (if configured and enabled) write the xstat field when the side-band status signals have been captured by the hardware during the transaction. 28

29 The following shows the descriptor definitions: Figure 6 - Receive DMA Descriptor Entry 29

30 9.3 Definitions Table 4: Receive Descriptor Definition Field name Position Width Description (bits) 1 word0, 1 Set to 1 by hardware for validation purposes. bit 31 0 word0, bit 30 1 Set to '0 by hardware for validation purposes. 1 word0, bit 29 0 word0, bit 28 1 word0, bit 27 VALID DISC MACERR DMAERR CHKSUM word0, bit 26 word0, bit 25 word0, bit 24 word0, bit 23 word0, bit 22 1 Set to 1 by hardware for validation purposes. 1 Set to '0 by hardware for validation purposes. 1 Set to 1 by hardware for validation purposes. 1 Set to 0 by software when initializing the descriptor. Set to 1 by the controller hardware to indicate it has written this word with the status (i.e. RX transaction completed and length information stored and error bits are valid). The software can clear this bit for its own purpose if it chooses to but will be ignored by the RX DMA hardware. 1 Read Only bit. Updated with RX Received IRQ event. If set to 1, the received Ethernet frame was not fully transferred due to total bytes in the frame to be received in full exceeding the maximum allowed (set in IO Register globalframebuffermax). This bit is only updated after the attempted reception of this entry. Writing to this bit by software causes no harm but has no effect. 1 Error indication from the FIFO interface. Indicates some receive error and the frame should be ignored by the software. 1 DMA or interface error. Indicates some local interface problem occurred during the transaction and the frame should be ignored. 1 Read Only bit. Updated with RX Received IRQ event. If set to 1, the received Ethernet frame has generated an arithmetic checksum (Protocol Checksum in the descriptor below). This bit is only updated after the attempted reception of this entry. Writing to this bit from software causes no harm but has no effect. XSTAT word0, bit 21 Note: If the MAC/SWITCH associated hardware is not included with checksum analysis on RX, then this bit is cleared upon packet receive. 1 xstat field is valid. Updated by hardware. The hardware has captured the xstat field from the FIFO interface during the transaction and the xstat field therefore contains valid information. 30

31 ERR0 ERR1 ERR2 ERR3 ERR4 Bytes Received Desc. Chksum Protocol Checksum xstat word0, bit 20 word0, bit 19 word0, bit 18 word0, bit 17 word0, bit 16 word0, bits 15:0 word1, bits31:24 word1, 15:0 words Error bit 0 indicator of MAC/SWITCH beyond FIFO. Set to 1 if MAC/SWITCH indicates Current Frame invalid length. 1 Error bit 1 indicator of MAC/SWITCH beyond FIFO. Set to 1 if MAC/SWITCH indicates Current Frame CRC-32 error. 1 Error bit 2 indicator of MAC/SWITCH beyond FIFO. Set to 1 if MAC/SWITCH indicates Frame was truncated due to FIFO-RX overflow. 1 Error bit 3 indicator of MAC/SWITCH beyond FIFO. Set to 1 if MAC/SWITCH indicates PHY signal error (gmii_rx_err from PHY to MAC/SWITCH) 1 Error bit 4 indicator of MAC/SWITCH beyond FIFO. Set to 1 if MAC/SWITCH indicates Current Frame implements VLAN tag. 8 Number of valid bytes stored in the data buffer of this descriptor. Updated by hardware. Note: This is the true number of bytes. The hardware will transfer always 32-bit/64-bit words from the FIFO, but then indicate which bytes are valid when the last data word was stored in the data buffer. The field is updated at the end of the transaction by the hardware (then also setting the VALID bit). 8 Not to be confused with the Protocol Checksum field, this is filled in when an Ethernet frame has been received. It is a one s-compliment checksum of the entire 8 word RX descriptor entry. This can be used by the Linux software device driver in conjunction with bits 31:27 to check if this entry is a valid memory structure. Data validation can be performed. Updated by hardware. 16 When an Ethernet frame is received and is valid, the hardware calculates the TCP or UDP protocol checksum if this functionality is included in the associated MAC/SWITCH hardware functionality. This field is the 16-bit result of the arithmetic analysis and can be used by the device driver to accept or reject the received Ethernet packet frame. Updated by hardware. The MAC/SWITCH hardware is not required to be told the offsets and sizes within the IP headers as it is not known what type of packet protocol will be received so it is all intelligent in the hardware. The Checksum bit (above) is set to 1 also. 128 A direct representation of up to 128-bit of side-band data that will be transferred to the FIFO interface at begin of a transaction (if XSTAT bit=1). The data is available for arbitrary use by the connected FIFO module and application. Updated by hardware. 31

32 9.4 Flow Illustration of Receive RX Engine (Landscape View) Figure 7 - Flow Chart Diagram of the RX Receive DMA Engine 32

33 10 TX DMA Mechanism 10.1 Overview AMBA DMA Controller (with AXI memory interface) The system driver (software) initializes two descriptor rings in system memory. Each ring is AHB- Lite IO-Register space which holds the descriptors one after each other. For each ring a read and write pointer (or number) register exists in the controller hardware. These pointers are used by the hardware to determine if there is data present for transmission. The pointer is a simple number giving the position of the descriptor within the descriptor ring (i.e. it is not the real address). When data is available, the current descriptor data is read from the IO-Registers in the hardware which provides all necessary information for the DMA engine to know where data is found (address) and how many bytes need to be copied. When the DMA completed processing the data of the descriptor, a done indication is given back to the descriptor selection function, which will start another transaction as indicated by the descriptor pointers. Note: The handshaking which descriptor had been transmitted is done by the read pointer which is updated by the hardware and can be inspected by the software TX Descriptor The descriptors are held in IO-Register in the DMA hardware accessible by the AHB-Lite interface. The size of the buffer (i.e. number of descriptors) is defined by hardware (parameterized option) and is limited to 256 entries. To access the descriptor the hardware uses pointers / counter variables to keep track of used and available descriptors. 33

34 The following shows the descriptor definitions: Figure 8 - Transmit DMA Descriptor Entry 34

35 10.3 Definitions Table 5: Transmit Descriptor Definition Field name Position Width Description (bits) IRQ word0, bit 31 1 When set, the hardware will trigger a transmit interrupt when the descriptor has been served (i.e. all buffer data has been copied). The system could use this for example to set the interrupt only on the very last descriptor within a sequence of descriptors to get informed when the complete list of data has been transferred, instead of XSTAT DMAERR XMITDONE DISC MACSUM CRCFWD word0, bit 30 word0, bit 29 word0, bit 28 word0, bit 27 word0, bit 26 Word0, bit25 receiving an interrupt per transmitted block. 1 xstat field is valid. The hardware will read the xstat field of the descriptor and produce it to the extended status bits at the FIFO interface. Typically the bit is set with the very first descriptor of a frame to ensure any side-band data is transferred and valid at the FIFO interface with the first data word written (and then stays constant). 1 Read Only bit. Updated with TX Transmission IRQ event. If set to 1, the transmission of this entry Ethernet frame was not successful due to an internal DMA error. This bit is only updated after the attempted transmission of this entry. Writing to this bit from software causes no harm but has no effect. 1 Read Only bit. Updated with TX Transmission IRQ event. If set to 1, the transmission of this entry Ethernet frame was completed irrespective of a FIFO MAC/SWITCH error. This bit is only updated after the attempted transmission of this entry. Writing to this bit from software causes no harm but has no effect. 1 Read Only bit. Updated with TX Transmission IRQ event. If set to 1, the transmission of this entry Ethernet frame was not fully transferred due to total bytes in the frame to be sent exceeding the maximum allowed (set in IO-Register globalframebuffermax). This bit is only updated after the attempted transmission of this entry. Writing to this bit from software causes no harm but has no effect. 1 If set to 0, the Descriptor fields MAC Checksum START, MAC Checksum COUNT, MAC Checksum INSERTION have no effect and are ignored during TX transmission. However, if set to 1, then those fields are used to program the connected MAC/SWITCH beyond the DMA Controller with values to calculate the UDP/TCP going checksum. This is if the MAC/SWITCH hardware is to calculate as opposed to the software device driver or if the user wishes, the Linux IP stack as normal. 1 CRC forward flag. If set to 1, the DMA TX core instructs the connected MAC/SWITCH not to append any CRC calculation to the packet frame being transmitted. It is assumed by the DMA hardware that the CRC has been constructed and stored by the 35

36 Bytes to Send MAC Checksum START MAC Checksum COUNT MAC Checksum INSERTION xstat Ethernet Frame Physical Address word0, bits word1, 31:22 word1, 21:12 word1, 11:0 words 2..5 software application layer. However, if set to 0 then the MAC/SWITCH hardware is allowed to be generated by the logic and appended to the frame instead. 16 Number of valid bytes stored in the data buffer of this descriptor. Note: This is the true number of bytes. The hardware will read always 32/64-bit words from memory, but then indicate which bytes are valid when transferring the very last word to the FIFO interface based on this information. 10 (If MACSUM=1) this word has to be set with the value offset into the Ethernet frame of the UDP/TCP checksum start byte to be arithmetically processed. This is passed onto the connected MAC/SWITCH that supports store/forward arithmetic. 10 (If MACSUM=1) this word has to be set with the consecutive bytes in the Ethernet frame for the UDP/TCP checksum to be arithmetically processed. This is passed onto the connected MAC/SWITCH that supports store/forward arithmetic. 12 (If MACSUM=1) this word has to be set with the value offset into the Ethernet frame of the UDP/TCP checksum 16-bit result word. This is in the TCP/UDP header. This is passed onto the connected MAC/SWITCH that supports store/forward arithmetic. 128 A direct representation of up to 128-bit of side-band data that will be transferred to the FIFO interface at begin of a transaction (if XSTAT bit=1). The data is available for arbitrary use by the connected FIFO module and application. Word7 32 Physical SDRAM memory location of this particular packet in memory. Unlike the RX descriptors that do not have this field and rely on a global MemPool register on a 2K/64K per packet basis, the TX is different. It has memory locations from the upper layer of software determining the location. 36

37 10.4 Flow Illustration of Transmit TX DMA Core (Landscape View) Figure 9 - Flow Chart Diagram of the TX DMA Engine 37