-
Notifications
You must be signed in to change notification settings - Fork 141
Registers
!! Registers
Block | Size | |
CPCI | 4MB | |
NF2 | 12MB | |
SRAM | 16MB | |
NF2 | 32MB | |
DRAM | 64MB |
The NF2 address area is divided into a number of "address spaces". At the top level the address is divided into the following sections: 16MB (includes CPCI address space), 16MB (SRAM), 32MB (typically used by the user data path) and 64MB (DRAM). Each of these spaces can be further subdivided. The first 16MB address space is divided into 4 x 4MB chunks -- the second of which is subdivided further into 256KB chunks. In the table below the Address Sequence illustrates which subdivisions to follow.
Module | Size | Address Range | |
NF2 Device Identification | 256KB | 0x0400000 – 0x043FFFF | |
MDIO | 256KB | 0x0440000 – 0x047FFFF | |
DMA | 256KB | 0x0480000 – 0x04CFFFF | |
??? | 256KB | 0x05C0000 – 0x05FFFFF | |
colspan="4" | ... | ||
??? | 256KB | 0x05C0000 – 0x05FFFFF | |
MAC Group 0 | 256KB | 0x0600000 – 0x063FFFF | |
MAC Group 1 | 256KB | 0x0640000 – 0x067FFFF | |
MAC Group 2 | 256KB | 0x0680000 – 0x06BFFFF | |
MAC Group 3 | 256KB | 0x06C0000 – 0x06FFFFF | |
CPU Queue 0 | 256KB | 0x0700000 – 0x073FFFF | |
CPU Queue 1 | 256KB | 0x0740000 – 0x077FFFF | |
CPU Queue 2 | 256KB | 0x0780000 – 0x07BFFFF | |
CPU Queue 3 | 256KB | 0x07C0000 – 0x07FFFFF | |
4MB block 2 | 4MB | 0x0800000 – 0x0BFFFFF | |
4MB block 3 | 4MB | 0x0C00000 – 0x0FFFFFF | |
SRAM | 16MB | 0x1000000 – 0x1FFFFFF | |
User Data Path | 32MB | 0x2000000 – 0x3FFFFFF | |
DRAM | 64MB | 0x4000000 – 0x7FFFFFF |
The NF2 device identification block allows software on the host to quickly identify the image loaded in the Virtex. The register layout is as follows:
Register | Description | Size (words) | |
MD5 Identifier | MD5 sum that identifies this block | 4 | |
Device ID | Unique identifier that identifies the project | 1 | |
Version | Version number of project | 1 | |
CPCI ID | Version and revision of the CPCI | 1 | |
ID string |
String identifying the device String should be NULL ('\0') terminated |
25 |
The UDP register path is a scan chain: each register block forwards the data to the next. There is support for reading the registers of other UDP modules (the reg_src) option, but this is not currently tested.
Attached are two useful files.
The first is a design by Nick Weaver for a reg_blk_grp.v. This is a simple design for a 1024 entry BlockRAM based register file for UDP applications.
The second is a dinky process_udp.c that directly creates both C and Verilog register defines (use sed to separate) in the simple format minishunt_udp.txt
---