wiki:crkit/Software/Firmware/Framework/R3_arch
close Warning: Can't synchronize with repository "(default)" (/common/SVN/crkit does not appear to be a Subversion repository.). Look in the Trac log for more information.

Version 16 (modified by khanhle, 12 years ago) ( diff )

--

R3 Architecture

Overview

With R3, we have included a dedicated control plane with RMAP processor which will handle all register map related accesses. In future releases, we may replace the RMAP processor with a real 32-bit soft processor such as Xilinx Microblaze, or equivalent processors.

The register maps associated with the control plane handle all Board related controls e.g. RF SPI, general purpose IOs, LEDs and so forth. Whereas, data plane centric register maps are maintained within the Tx and Rx Application modules. Within the APP module, we have an option of having a top level RMAP, and/or an application specific RMAP. Usually, the top level RMAP is shared among multiple applications, whereas application specific RMAPs are only designed for a particular application.

Figure 1 - R3 architecture overview



R3 architecture consists of following modules :

  • Ethernet Port - Ethernet framing function,
    • Rx - receives ethernet frames from Host. Performs CRC checking, and forwards error free payload to packet processor.
    • Tx - transmits ethernet frames to Host. Generates Ethernet header and CRC, IP payload is provided by packet processor.
  • Packet Processor - IP layer processing
    • Packet classification - RMAP, Data, and other (such as ARP and DHCP packets)
    • UDP is used for board level communication e.g. RMAP and Data packets
  • APP - User specific application

  • RF Port - DAC/ADC interfacing
  • Control Plane - RMAP and RF control
  • Timing Control - system wide clock control using clock enables

From Host, we can control the hardware (RMAP read/write operations) by sending RMAP ethernet frame messages. The packet classifier classifies and forwards packets according to its type :

  • RMAP packets -> RMAP Processor
  • Data packets -> Tx Buffer for APP processing
  • Other packets -> TCP/IP stack

For RMAP read operations, read data must be forwarded back to Host. This is accomplished by following operations :

  1. RMAP Processor forwards read data to Rx Memory Controller. Note : shared access to Rx buffer with dataflow.
  2. Generate IP and Ethernet frame for transmission back to host. Some control header information are added in the payload section for Host RMAP read synchronization.

Global Memory Map

R3 global memory map is currently divided into 4 regions : Common control, Common Interrupt Control, Receiver and Transmitter. 65Kbytes are reserved for each region. The total number of address bits are 32-bit, but we will only use the lower 16-bits per region e.g. 65Kbytes per region. Therefore, bits31-28 are used for region address decoding between the individual regions as illustrated in figure 2.

Table 1 - R3 Global Memory Map

Instance Base AddressSize Description
Reserved 0x00000000-0x0FFFFFFC- Future use
Common Control 0x10000000-0x1000FFFC65K Control Plane register map e.g. SPI, LEDs, and board level IO
Common INTC 0x10010000-0x1001FFFC65K Interrupt Controller map. Individual interrupt lines from all RMAPs are consolidated in a single location. Once an interrupt is set by HW, a status messaging packet is sent to Host. Host shall read the INTC status register to identify which of the RMAP regions has triggered an interrupt e.g. coarse parsing, followed by fine parsing
Timing Control 0x10020000-0x1002FFFC65K address range for timing controller
Ethernet Port 0x10030000-0x1003FFFC65K address range for Tx and Rx Ethernet ports
Packet Processor0x10040000-0x1004FFFC65K address range for packet processor
Tx APP 0x10050000-0x1005FFFC65K address range for Tx Application
Rx APP 0x10060000-0x1006FFFC65K address range for Tx Application
RF Port - DAC 0x10070000-0x1007FFFC65K address range for DAC interfacing module
RF Port - ADC 0x10080000-0x1008FFFC65K address range for ADC interfacing module
Reserved 0x10090000-0xFFFFFFFC- Future use


Figure 2 - R3 Top Address Decoding



Packet Formatting

In this section, the packet structure is detailed. The

Figure 3 - Packet Format



for Host -> HW, and HW -> Host directions. Some header information are appended to provide additional control information.
Host -> HW : two types of Ethernet frames e.g. rmap and data frames.
HW -> Host : two types of Ethernet frames e.g. rmap read and data. The data frames are further classified in additional subtypes such as generic data, FFT data structures and so forth. Host may perform additional processing on the data structures.

Segmentation - this function is performed by the 'Tx Ethernet Interface' module. This module will automatically segment the data structure if size is greater than 1500 bytes (payload is stored in Rx Buffer). Some control information are appended to denote first, intermediate and last segment. Refer to HW -> Host for further details.

Control Flow

As with previous revisions, R3 control flow is message-based. Host sends commands to HW, where they get parsed and acted on accordingly. R3 control flow scheme is detailed in the Control Flow Diagram.

Multi-clocks Synchronization



Block Level Specifications

XMTR
RCVR
Control Plane


FPGA Architecture

The modularity of the FPGA architecture design provides a path for upgradeability. All main components can be upgraded or replaced as long as the integrity of IO interfaces are maintained.

Register Maps



Return ..

Attachments (3)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.