QoS Tab - 1.1 English - PG313

The quality of service (QoS) tab of the Customize IP dialog box is shown in the following figure and allows the configuration of the quality of service properties of every path defined in the axi_noc instance.

Figure 1. QoS Tab

• The first column of the QoS tab shows a tree structure of the connectivity defined in the Connectivity tab. The top of each tree (left aligned port names) are the NoC ingress ports; in the figure, S00_AXI and S01_AXI. Shown under each ingress port are the associated rows for each connected egress port.
• The second column defines the read traffic class. The possible values are LOW_LATENCY, ISOCHRONOUS, and BEST_EFFORT (default). The traffic class applies to all connections originating from the given ingress port.
• The third column defines the write traffic class. The possible values are ISOCHRONOUS and BEST_EFFORT. LOW_LATENCY is not supported for write traffic. As with read traffic, the write traffic class applies to all connections originating at the given ingress port.
• The fourth column indicates whether this NoC instance owns the QoS setting for a given path. A NoC path can go through multiple NoC instances using INI. QoS settings are taken from the NoC instance that owns the QoS and path. QoS is ignored when a NoC instance does not own the path. Ownership is at the transition from an NMU or strategy=Driver to an NSU, MC, or strategy=Load. A value of 'pending' means the ownership will be calculated during validate, or by clicking the Run NoC DRCs button above. For a value of 'error', validate or click the Run NoC DRCs button above to see error details in the Tcl Console and messages window.
• The fifth column defines the Read bandwidth expressed in MB/s. Allowed values range from 0 (no read traffic is accepted) to the maximum data bandwidth of the NoC physical channel.
  Note: Read bandwidth is expressed in Gbps if the Gbps option is checked (Gbps = 8*MB/s/1000).
• The sixth column defines the Write bandwidth expressed in MB/s. Allowed values range from 0 (no write traffic is accepted) to the maximum data bandwidth of the NoC physical channel.
  Note: Write bandwidth is expressed in Gbps if the Gbps option is checked (Gbps = 8*MB/s/1000).
  Note: The Gbps check box allows bandwidth conversion between MB/s and Gbps.

  (Gbps = MB/s*8/1000)

  Owns QoS and Path

  A NoC path can go through multiple NoC instances using INI. QoS settings are taken from the NoC instance that owns the QoS and Path. QoS is ignored when a NoC does not own the path. Ownership is at the transition from an NMU or strategy=Driver to an NSU, MC, or strategy=Load.

  A value of 'pending' means the ownership will be calculated during validate, or by clicking the Run NoC DRCs button above. For a value of 'error', validate or click the 'Run NoC DRCs' button above to see error details in the Tcl Console and messages window.

  Note: If Owns QoS and Path is no then all settings BW and traffic class will be ignored.

  Run NoC DRCs

  Run NoC DRCs across the design. Errors are listed in the Tcl Console and messages window. Update 'pending' entries in the 'Owns QoS' column by calculating ownership across the design. A NoC path can go through multiple NoC instances using INI. QoS settings are taken from the NoC instance that owns the QoS and Path. QoS is ignored when a NoC does not own the path. Ownership is at the transition from an NMU or strategy=Driver to an NSU, MC, or strategy=Load.

  The QoS tab Advanced check box enables the following columns:

  Figure 2. Advanced QoS Tab
  
  
  • Read/Write Ave Burst Length:Average burst length in beats:
    Note: The NoC Compiler uses the average burst length to predict packet overhead. This influences the overall bandwidth required to meet QoS. See Packetization Overhead for more details.
    • Lower Limit: 1
    • Upper Limit: average_burst_length*master_data_width/8 = 4096 (4 KB data limit)
  • Exclusive-Routing Group/Separate-Routing Group:
    • Both of these features are intended to support functional safety applications. The edit boxes allow you to enter arbitrary strings to define groups of NoC routing nets: nets with the same string are members of the same group. Nets in a given “exclusive routing group” are allowed to share physical resources with other members of the group, but are guaranteed by the compiler not to share resources with any nets outside of the group. Analogously, nets in a given “separate routing group” are guaranteed not to share resources with other members of the group, but can share resources with nets outside of the group.

      Paths in separate routing groups share physical routes but are isolated through virtual channels. Paths in exclusive routing groups do not share physical routes. Exclusive routing groups can result in adjacent VNoC usage, resulting in increased structural latency. Separate routing groups with different streams active at the same time will result in queuing latency.

  Note: Refer to Multi-SLR NoC Boot Pathsfor information about how the boot path will impact use of exclusive routing groups.