-
Notifications
You must be signed in to change notification settings - Fork 140
RegSystemConfigFileElements
Description: Define the meaning of individual bits within a (simple) type.
Parent elements: nf:type
Attributes: None
Child elements: nf:pos, nf:pos_lo, nf:pos_hi
Example:
<nf:type xsi:type="nf:SimpleType"> <nf:name>mac_grp_control</nf:name> <nf:description>MAC group control register</nf:description> <nf:width>9</nf:width> <nf:bitmask> <nf:name>tx_queue_disable</nf:name> <nf:description>Disable the TX queue</nf:description> <nf:pos>0</nf:pos> </nf:bitmask>Define bit 0 of the mac_grp_control type to be the TX queue disable. Example from lib/verilog/core/io_queues/ethernet_mac/xml/ethernet_mac.xml
Description:
Size of memory block to allocate to the instance (in bytes).
Can append 'k' to indicate kilobytes (1,024) or 'm' to indicate megabytes (1,048,576).
Parent elements: nf:module
Attributes: None
Child elements: None
Example:
<nf:module> <nf:name>nf2_mac_grp</nf:name> <nf:prefix>mac_grp</nf:prefix> <nf:location>core</nf:location> <nf:description>Ethernet MAC group</nf:description> <nf:blocksize>256k</nf:blocksize> ...
Description: Declare a constant value. The constant can be used in code (Verilog, C, Perl) or in the register system.
Parent elements: nf:constants
Attributes: None
Child elements: nf:name, nf:description, nf:width, nf:value
Example:
<nf:constant> <nf:name>MAX_PHY_PORTS</nf:name> <nf:description>Maximum number of phy ports</nf:description> <nf:value>4</nf:value> </nf:constant>Declares a constant named MAX_PHY_PORTS with the value 4.
Description: Collection of constants.
Parent elements: nf:global, nf:module, nf:project, nf:shared
Attributes: None
Child elements: nf:constant
Example:
<nf:constants> <nf:constant> <nf:name>MAX_PHY_PORTS</nf:name> <nf:description>Maximum number of phy ports</nf:description> <nf:value>4</nf:value> </nf:constant> </nf:constants>
Description: Number of entries (depth) in a table type.
Parent elements: nf:type
Attributes: None
Child elements: None
Example:
<nf:type xsi:type="nf:TableType" table_type="indirect"> <nf:name>arp_table</nf:name> <nf:description>The ARP table for mapping IPs to MACs</nf:description> <nf:depth>ARP_TABLE_DEPTH</nf:depth> <nf:entry_type>arp_table_entry</nf:entry_type> <nf:width>3 * 32</nf:width> </nf:type>
The depth of the table is specified as ARP_TABLE_DEPTH (a constant defined elsewhere). This example is taken from lib/verilog/core/output_port_lookup/cam_router/xml/cam_router.xml
Description: Description of the entity being declared.
Parent elements: nf:constant, nf:field, nf:module, nf:project, nf:register_group, nf:register, nf:shared, nf:type
Attributes: None
Child elements: None
Example:
<nf:register> <nf:name>arp_num_misses</nf:name> <nf:description>Number of arp misses</nf:description> <nf:type>counter32</nf:type> </nf:register>
Description: Unique device ID assigned to the project. Device IDs should be register on the Device ID List.
Parent elements: nf:project
Attributes: None
Child elements: None
Example:
<nf:project> <nf:name>Project example</nf:name> <nf:description>Example of a project.xml file</nf:description> ... <nf:dev_id>100</nf:dev_id>
Specifies a device ID of 100 for the project named "Project example".
Description: Type of each "entry"/row in a table type. Types must be declared.
Parent elements: nf:table
Attributes: None
Child elements: None
Example:
<nf:type xsi:type="nf:CompoundType"> <nf:name>arp_table_entry</nf:name> <nf:description>An entry in the ARP table -- contains an IP address and a corresponding Ethernet MAC address</nf:description> ... </nf:type> <nf:type xsi:type="nf:TableType" table_type="indirect"> <nf:name>arp_table</nf:name> <nf:description>The ARP table for mapping IPs to MACs</nf:description> <nf:depth>ARP_TABLE_DEPTH</nf:depth> <nf:entry_type>arp_table_entry</nf:entry_type> </nf:type>
The entry type for the ARP table is "arp_table_entry". This type is declared as well. Example from lib/verilog/core/output_port_lookup/cam_router/xml/cam_router.xml
Description: A field in a compound type. (Compound types assemble a number of fields.)
Parent elements: nf:type
Attributes: None
Child elements: nf:name, nf:description, nf:type, nf:width
Example:
<nf:type xsi:type="nf:CompoundType"> <nf:name>arp_table_entry</nf:name> <nf:description>An entry in the ARP table -- contains an IP address and a corresponding Ethernet MAC address</nf:description> <nf:field> <nf:name>mac</nf:name> <nf:description>ARP MAC</nf:description> <nf:type>ethernet_addr</nf:type> </nf:field>
Definition of a field within the arp_table_entry type. Example from lib/verilog/core/output_port_lookup/cam_router/xml/cam_router.xml
Description: Force the module instance to be allocated memory at this memory address.
Parent elements: nf:module
Attributes: None
Child elements: None
Example:
<nf:module> <nf:name>device_id</nf:name> <nf:prefix>dev_id</nf:prefix> ... <nf:force_base>0x0400000</nf:force_base>
Force the device_id module to be located at address 0x0400000. Example from lib/verilog/core/utils/xml/device_id_reg.xml
Description: Global configuration file. Allows constants and types to be declared that are shared across all projects.
- Parent elements: *
Attributes: None
Child elements: None nf:constants, nf:types
Example:
<nf:global> <nf:constants> <nf:constant> <nf:name>MAX_PHY_PORTS</nf:name> <nf:description>Maximum number of phy ports</nf:description> <nf:value>4</nf:value> </nf:constant>
Example from lib/verilog/core/common/xml/global.xml
Description: A memory allocation group.
Parent elements: nf:memalloc
Attributes:
- name : The name of the group. This must be one of the following:
Name | Address range | Description |
cpci | 0x0000000 - 0x03fffff | Modules instantiated inside the CPCI (Spartan) |
core1 | 0x0400000 - 0x07fffff | Modules instantiated outside the user data path, connected to the first arbiter in nf_core |
core2 | 0x0800000 - 0x0bfffff | Modules instantiated outside the user data path, connected to the second arbiter in nf_core |
core3 | 0x0c00000 - 0x0ffffff | Modules instantiated outside the user data path, connected to the third arbiter in nf_core |
udp | 0x2000000 - 0x3ffffff | Modules instantiated inside the user data path |
Modules should be added to a group matching their location (see nf:location). For example, a module with the location of "core" should be added to one of the three core groups.
Child elements: nf:instance
Example:
<nf:memalloc layout="reference"> <nf:group name="core1"> <nf:instance name="device_id" /> <nf:instance name="dma" base="0x0500000"/> <nf:instance name="mdio" /> <nf:instance name="nf2_mac_grp" count="4" /> <nf:instance name="cpu_dma_queue" count="4" /> </nf:group>
The "core1" group instantiates the following modules: device_id, dma, mdio, nf2_mac_grp (four instances), and cpu_dma_queue (four instances). Example from projects/reference_router/include/project.xml.
Description: An instance within a memory allocation group (nf:group)
Parent elements: nf:group
Attributes:
- name : The module to instantiate. This must be the name declared in the module's configuration file. (It is not the module directory name.)
- count : The number of instances to instantiate. Default is 1.
- base : The base address to use if possible. The register system allocates an address by default.
Example:
<nf:group name="core1"> <nf:instance name="device_id" /> <nf:instance name="dma" base="0x0500000"/> <nf:instance name="mdio" /> <nf:instance name="nf2_mac_grp" count="4" /> <nf:instance name="cpu_dma_queue" count="4" /> </nf:group>
Instantiation of the following modules: device_id, dma (base address 0x0500000 requested), mdio, nf2_mac_grp (four instances), and cpu_dma_queue (four instances). Example from projects/reference_router/include/project.xml.
Description: Number of instances in a register group. This is the number of times each of the registers in the group should be repeated.
Parent elements: nf:register_group
Attributes: None
Child elements: None
Example:
<nf:name>output_queues</nf:name> <nf:prefix>oq</nf:prefix> ... <nf:register_group> <nf:name>queue</nf:name> <nf:instances>:NUM_OUTPUT_QUEUES</nf:instances> <nf:register> <nf:name>ctrl</nf:name> <nf:description>Control register</nf:description> <nf:type>oq_control</nf:type> </nf:register>
Creation of a register group in the output queues. Example from lib/verilog/core/output_queues/sram_rr_output_queues/xml/sram_rr_output_queues.xml
In this example, NUM_OUTPUT_QUEUES (8) groups will be created. Each group will contain one register, named ctrl. The resultant registers as they appear in the C header file are:
#define OQ_QUEUE_0_CTRL_REG 0x2001000 #define OQ_QUEUE_1_CTRL_REG 0x2001200 #define OQ_QUEUE_2_CTRL_REG 0x2001400 #define OQ_QUEUE_3_CTRL_REG 0x2001600 #define OQ_QUEUE_4_CTRL_REG 0x2001800 #define OQ_QUEUE_5_CTRL_REG 0x2001a00 #define OQ_QUEUE_6_CTRL_REG 0x2001c00 #define OQ_QUEUE_7_CTRL_REG 0x2001e00
Note: In C and Perl, the register names are formed as <module prefix>_<group name>_<instance number>_<register name>_REG
Description: Amount of memory to be allocated to each instance (in bytes). The register group will occupy all available memory within the instance (limited to powers of 2), with the memory divided equally between all instances (rounding the number of instances to a power of 2).
Parent elements: nf:register_group
Attributes: None
Child elements: None
Example:
<nf:register_group> <nf:name>phy</nf:name> <nf:instances>:MAX_PHY_PORTS</nf:instances> <nf:instance_size>0x80</nf:instance_size> <nf:register>
Each register group is 0x80 (128 bytes) in size. Example from lib/verilog/core/io/mdio/xml/mdio.xml
Description: Location within the NetFPGA where the module can be instantiated. Valid locations are:
Location | Description |
cpci | Module should be instantiated in the CPCI |
core | Module should be instantiated in the Virtex outside the user data path |
udp | Module should be instantiated in the Virtex inside the user data path |
The location specified for a module dictates which groups (nf:group) it can be added to.
- Parent elements: *
Attributes: None
Child elements: None
Example:
<nf:module> <nf:name>output_queues</nf:name> <nf:prefix>oq</nf:prefix> <nf:location>udp</nf:location>The output queues module should be instantiated within the User Data Path (UDP). Example from lib/verilog/core/output_queues/sram_rr_output_queues/xml/sram_rr_output_queues.xml
Description: Memory allocation to use for the project.
Parent elements: nf:project
Attributes:
- layout : The memory layout to use. Valid layouts are:
Layout | Description |
cpci | CPCI (Spartan) design. Locate all registers in the region 0x0000000 - 0x03fffff |
reference | Virtex design with reference layout. See FIXME |
freeform | Virtex design without a fixed layout. See FIXME |
Child elements: nf:group
Example:
<nf:memalloc layout="reference"> <nf:group name="core1"> <nf:instance name="device_id" /> <nf:instance name="dma" base="0x0500000"/> <nf:instance name="mdio" /> <nf:instance name="nf2_mac_grp" count="4" /> <nf:instance name="cpu_dma_queue" count="4" /> </nf:group> ...
Memory allocation using the reference layout. The "core1" group is shown, other groups have been omitted. Example from projects/reference_router/include/project.xml
Description: Module configuration file. Declares information about a module include name, location, size, registers, types and constants.
Parent elements: None
Attributes: None
Child elements: nf:name, nf:prefix, nf:description, nf:location, nf:blocksize, nf:preferred_base, nf:force_base, nf:registers, nf:constants, nf:types, nf:use_shared
Example:
<nf:module> <nf:name>output_queues</nf:name> <nf:prefix>oq</nf:prefix> <nf:location>udp</nf:location> <nf:description>SRAM-based output queue using round-robin removal</nf:description> <nf:blocksize>4k</nf:blocksize> <nf:registers> ...Example from projects/reference_router/include/project.xml
Description: Name of the entity being declared. This name is used when referencing the entity within the register system.
Parent elements: nf:constant, nf:field, nf:module, nf:project, nf:register_group, nf:register, nf:type
Attributes: None
Child elements: None
Example:
<nf:module> <nf:name>output_queues</nf:name>Example from projects/reference_router/include/project.xml
Description: Bit number of a single-bit field within a (simple) type.
Parent elements: nf:type
Attributes: None
Child elements: None
Example:
<nf:name>mac_grp_control</nf:name> <nf:description>MAC group control register</nf:description> <nf:width>9</nf:width> <nf:bitmask> <nf:name>tx_queue_disable</nf:name> <nf:description>Disable the TX queue</nf:description> <nf:pos>0</nf:pos> </nf:bitmask>Define bit 0 of the mac_grp_control type to be the TX queue disable. Example from lib/verilog/core/io_queues/ethernet_mac/xml/ethernet_mac.xml
Description: Bit number of the most-significant bit of a multi-bit field within a (simple) type.
Parent elements: nf:type
Attributes: None
Child elements: None
Example:
<nf:type xsi:type="nf:SimpleType"> <nf:name>cpci_id</nf:name> <nf:description>CPCI ID</nf:description> <nf:width>32</nf:width> <nf:bitmask> <nf:name>version</nf:name> <nf:description>Version number (major)</nf:description> <nf:pos_lo>0</nf:pos_lo> <nf:pos_hi>23</nf:pos_hi> </nf:bitmask> <nf:bitmask> <nf:name>revision</nf:name> <nf:description>Revision number (minor)</nf:description> <nf:pos_lo>24</nf:pos_lo> <nf:pos_hi>31</nf:pos_hi> </nf:bitmask> </nf:type>Definition of the version and revision fields within the cpci_id type. Example from projects/cpci/include/cpci_regs.xml
Description: Bit number of the least-significant bit of a multi-bit field within a (simple) type.
Parent elements: nf:type
Attributes: None
Child elements: None
Example:
<nf:type xsi:type="nf:SimpleType"> <nf:name>cpci_id</nf:name> <nf:description>CPCI ID</nf:description> <nf:width>32</nf:width> <nf:bitmask> <nf:name>version</nf:name> <nf:description>Version number (major)</nf:description> <nf:pos_lo>0</nf:pos_lo> <nf:pos_hi>23</nf:pos_hi> </nf:bitmask> <nf:bitmask> <nf:name>revision</nf:name> <nf:description>Revision number (minor)</nf:description> <nf:pos_lo>24</nf:pos_lo> <nf:pos_hi>31</nf:pos_hi> </nf:bitmask> </nf:type>Definition of the version and revision fields within the cpci_id type. Example from projects/cpci/include/cpci_regs.xml
Description: Specify the preferred base address where the module instance should be allocated memory. Since this address is only preferred, the register system can locate it elsewhere if necessary.
This element is useful for modules that may be instantiated multiple times within a project (eg. the Ethernet MAC). The register system will try to place the modules consecutively in memory starting at the preferred address.
Parent elements: nf:module
Attributes: None
Child elements: None
Example:
<nf:module> <nf:name>nf2_mac_grp</nf:name> <nf:prefix>mac_grp</nf:prefix> <nf:location>core</nf:location> <nf:description>Ethernet MAC group</nf:description> <nf:blocksize>256k</nf:blocksize> <nf:preferred_base>0x0600000</nf:preferred_base>Request that the Ethernet MAC group be located at address 0x0600000. Example from lib/verilog/core/io_queues/ethernet_mac/xml/ethernet_mac.xml
Description: Prefix to prepend to all registers and constants within the module. The module name and prefix may be different.
Global constants can be accessed by prefixing the constant with a colon (:).
Parent elements: nf:module
Attributes: None
Child elements: None
Example:
<nf:module> <nf:name>router_op_lut</nf:name> <nf:prefix>router_op_lut</nf:prefix> ... <nf:registers> <nf:register> <nf:name>arp_num_misses</nf:name> <nf:description>Number of arp misses</nf:description> <nf:type>counter32</nf:type> </nf:register>The prefix for the module is router_op_lut. The register shown here will be named ROUTER_OP_LUT_ARP_NUM_MISSES (with _REG appended in C/Perl). Example from lib/verilog/core/output_port_lookup/cam_router/xml/cam_router.xml
Description: Project configuration file. Specifies information about a project including the name, description, list of modules, and memory layout to use.
Parent elements: None
Attributes: None
Child elements: nf:constant, nf:field, nf:module, nf:project, nf:register_group, nf:register, nf:type
Example:
<nf:project> <nf:name>Reference router</nf:name> <nf:description>Reference IPv4 router</nf:description> ... <nf:use_modules> core/io_queues/cpu_dma_queue core/io_queues/ethernet_mac ... </nf:use_modules> <nf:memalloc layout="reference"> ... </nf:memalloc> </nf:project>Example from projects/reference_router/include/project.xml
Description: A single register.
Parent elements: nf:registers, nf:register_group
Attributes: None
Child elements: nf:name, nf:description, nf:type, nf:width
Example:
<nf:registers> <nf:register> <nf:name>arp_num_misses</nf:name> <nf:description>Number of arp misses</nf:description> <nf:type>counter32</nf:type> </nf:register>
Description: A group of registers that are repeated across a number of "instances". These are useful when a set of registers needs to be maintained per port. They are used in the output queues to maintain counters for each queue (one queue per port).
Parent elements: nf:registers
Attributes: None
Child elements: nf:name, nf:description, nf:instances, nf:instance_size, nf:register
Example:
<nf:registers> <nf:register_group> <nf:name>queue</nf:name> <nf:instances>:NUM_OUTPUT_QUEUES</nf:instances> <nf:register> <nf:name>ctrl</nf:name> <nf:description>Control register</nf:description> <nf:type>oq_control</nf:type> </nf:register> <nf:register> <nf:name>num_pkt_bytes_stored</nf:name> <nf:description>Number of packet bytes stored</nf:description> <nf:type>sram_byte_cnt</nf:type> </nf:register> ...Register group defined within the output queues. Each group has a control register (to enable/disable the particular queue), and a counter of the number of bytes stored. Other registers are defined but not shown here. Example from lib/verilog/core/output_queues/sram_rr_output_queues/xml/sram_rr_output_queues.xml
Description: List of registers provided by the module.
Parent elements: nf:module
Attributes: None
Child elements: nf:register, nf:register_group,
Example:
<nf:module> <nf:name>device_id</nf:name> ... <nf:registers> <nf:register> <nf:name>md5</nf:name> <nf:description>MD5 hash identifying the module</nf:description> <nf:type>md5sum</nf:type> </nf:register>Example from lib/verilog/core/utils/xml/device_id_reg.xml
Description: Shared configuration file. Allows definition of constants and types that will be used by some modules.
Parent elements: None
Attributes: None
Child elements: nf:description, nf:constants, nf:types
Example:
<nf:shared> <nf:description>Example shared constants</nf:description> <nf:constants> <nf:constant> <nf:name>MAX_ITEMS</nf:name> <nf:value>10</nf:value> </nf:constant> ...
Description: Declare a new type (see FIXME for a discussion of why types are used). Four different types exist: simple, bitmask, compound, and table. All except the bitmask are declared directly in the nf:types section. (Bitmasks are declared as parts of a simple type.)
Each of the types is documented below. To declare a particular type, the type must be specified via the xsi:type attribute. As an example:
Parent elements: nf:types
Attributes: (Common to all types)
- xsi :type : Particular type to declare. Must be one of "SimpleType", "CompoundType", or "BitmaskType".
Example:
<nf:type xsi:type="nf:SimpleType"> <nf:name>sram_pkt_cnt</nf:name> <nf:width>SRAM_PKT_CNT_WIDTH</nf:width> </nf:type>Example from lib/verilog/core/output_queues/sram_rr_output_queues/xml/sram_rr_output_queues.xml
Description: Simple types represent either a single data value or a data value made up of bitmasks fields. (Note: Compound types serve a similar purpose to simple types with bitmasks but allow the grouping of multiple types to form an aggregate type.)
Attributes: None specific to nf:SimpleType
Child elements: (Specific to nf:SimpleType) nf:width, nf:bitmask
Example:
<nf:type xsi:type="nf:SimpleType"> <nf:name>sram_pkt_cnt</nf:name> <nf:width>SRAM_PKT_CNT_WIDTH</nf:width> </nf:type>Example from lib/verilog/core/output_queues/sram_rr_output_queues/xml/sram_rr_output_queues.xml
Description: Represents a type composed of other types. Similar to a struct in C. Useful when grouping related information.
Attributes: None specific to nf:CompoundType
Child elements: (Specific to nf:CompoundType) nf:field
Example:
<nf:type xsi:type="nf:CompoundType"> <nf:name>arp_table_entry</nf:name> <nf:description>An entry in the ARP table -- contains an IP address and a corresponding Ethernet MAC address</nf:description> <nf:field> <nf:name>mac</nf:name> <nf:description>ARP MAC</nf:description> <nf:type>ethernet_addr</nf:type> </nf:field> <nf:field> <nf:name>next_hop_ip</nf:name> <nf:description>ARP next hop IP address</nf:description> <nf:type>ip_addr</nf:type> </nf:field> </nf:type>Example from lib/verilog/core/output_port_lookup/cam_router/xml/cam_router.xml
Description: Type to describe a table. Tables consist of multiple rows, with each row having the same structure.
Currently the only table type supported (see attributes) is an "indirect" table. Indirect tables are tables which have one or more registers that hold a single row, and read address and write address registers for reading/writing the row from/to the table.
Attributes: (Specific to nf:TableType)
- table_type : The type of table. Currently all tables must be "indirect".
Example:
<nf:type xsi:type="nf:TableType" table_type="indirect"> <nf:name>arp_table</nf:name> <nf:description>The ARP table for mapping IPs to MACs</nf:description> <nf:depth>ARP_TABLE_DEPTH</nf:depth> <nf:entry_type>arp_table_entry</nf:entry_type> <nf:width>3 * 32</nf:width> </nf:type>Example from lib/verilog/core/output_port_lookup/cam_router/xml/cam_router.xml
Description: Specify the type to use for a given register.
Parent elements: nf:register
Attributes: None
Child elements: None
Example:
<nf:register> <nf:name>arp_num_misses</nf:name> <nf:description>Number of arp misses</nf:description> <nf:type>counter32</nf:type> </nf:register>Declare the arp_num_misses_ register to be a 32-bit counter. Example from =lib/verilog/core/output_port_lookup/cam_router/xml/cam_router.xml
Description: Collection of types.
Parent elements: nf:module, nf:project, nf:shared, nf:type
Attributes: None
Child elements: nf:type
Example:
<nf:types> <nf:type xsi:type="nf:SimpleType"> <nf:name>sram_pkt_cnt</nf:name> <nf:width>SRAM_PKT_CNT_WIDTH</nf:width> </nf:type>Example from lib/verilog/core/output_queues/sram_rr_output_queues/xml/sram_rr_output_queues.xml
Description: List of library modules to include in the project.
Parent elements: nf:project
Attributes: None
Child elements: None
Example:
<nf:project> <nf:name>Reference router</nf:name> <nf:description>Reference IPv4 router</nf:description> ... <nf:use_modules> core/io_queues/cpu_dma_queue core/io_queues/ethernet_mac ... </nf:use_modules>Example from projects/reference_router/include/project.xml
Description: List of shared configuration files to use.
Parent elements: nf:module
Attributes: None
Child elements: None
Example:
<nf:module> <nf:name>simple_module</nf:name> ... <nf:use_shared> contrib/stanford/example/xml/example.xml </nf:use_shared> </nf:module>
Description: Value of a constant. Can be a value or a simple mathematical expression, possibly referencing other constants.
Parent elements: nf:constant
Attributes: None
Child elements: None
Example:
<nf:constant> <nf:name>MD5SUM_LENGTH</nf:name> <nf:description>Length of MD5 sum (bits)</nf:description> <nf:value>128</nf:value> </nf:constant> <nf:constant> <nf:name>NON_STR_REGS</nf:name> <nf:description>Number of non string registers</nf:description> <nf:value>(MD5SUM_LENGTH/32) + 3</nf:value> </nf:constant>The value of the NON_STR_REGS constant is an expression involving the MD5SUM_LENGTH constant. Example from lib/verilog/core/utils/xml/device_id_reg.xml
Description: Major version number. (Version number is of the form: major.minor.revision)
Parent elements: nf:project
Attributes: None
Child elements: None
Example:
<nf:project> <nf:name>Reference router</nf:name> <nf:description>Reference IPv4 router</nf:description> <nf:version_major>1</nf:version_major> <nf:version_minor>0</nf:version_minor> <nf:version_revision>0</nf:version_revision> ...Example from projects/reference_router/include/project.xml.
Description: Minor version number. (Version number is of the form: major.minor.revision)
Parent elements: nf:project
Attributes: None
Child elements: None
Example:
<nf:project> <nf:name>Reference router</nf:name> <nf:description>Reference IPv4 router</nf:description> <nf:version_major>1</nf:version_major> <nf:version_minor>0</nf:version_minor> <nf:version_revision>0</nf:version_revision> ...Example from projects/reference_router/include/project.xml.
Description: Revision version number. (Version number is of the form: major.minor.revision)
Parent elements: nf:project
Attributes: None
Child elements: None
Example:
<nf:project> <nf:name>Reference router</nf:name> <nf:description>Reference IPv4 router</nf:description> <nf:version_major>1</nf:version_major> <nf:version_minor>0</nf:version_minor> <nf:version_revision>0</nf:version_revision> ...Example from projects/reference_router/include/project.xml.
Description: Width (in bits) of a constant, type, register, or field.
Parent elements: nf:constant, nf:field, nf:register, nf:type
Attributes: None
Child elements: None
Example:
<nf:type xsi:type="nf:SimpleType"> <nf:name>cpci_id</nf:name> <nf:description>CPCI ID</nf:description> <nf:width>32</nf:width>Example from projects/cpci/include/cpci_regs.xml
Refer to the main Register System page for more information.