NoC DFX DRCs in IP Integrator: Problems and Solutions - 2022.1 English

NoC Paths must be Owned by Static if they have a Static NMU

NoC DFX DRC

[BD 41-2479] NoC DFX Rule: NoC paths must be owned by the static if 
they have a static NoC master (must have INI strategy=load). 
The path from NoC Master (axi slave) /static_region/axi_noc_0/S00_AXI to 
/rp1/S00_INI (INI strategy set by user) is not static. 
To fix: set the INI strategy on INI interfaces for this path to 'load'

Reason

The NMU (for example, corresponding to NoC S00_AXI) is configured to route to a specific NSU. By having the static NMU own the path, the part of the NMU that determines the destination NSU is also static and non-changing. If the RM owned the path then a part of the static NMU would also have to be reconfigured when the path is changed. In order to keep the static NMU fully static the NMU must own the path.

Path ownership of the NoC path is crucial in determining the Quality of Serivce (QoS) for that path. For the NoC Paths across the DFX boundary, if the NoC master is in the static region, Quality of Service should be determined by the static region NoC instance. According to NoC rules, QoS is decided by the NoC instance who owns the path. This also enables the user to selectively tune the QoS and Bandwidth to required value across the DFX boundary and lock it down for multiple RM variants.

Solution

When the NoC INI strategy is selected as Single Load, the Driver (NMU) owns the DFX path and decides the QoS. This is required for the boundary paths of DFX when driver NMU is in the static region. When the NoC INI strategy is selected as Single Driver, the Load (NSU) will own the DFX path. This is not allowed for DFX boundary path since the NSUs in reconfigurable partition can changed over different RM variants and boundary path cannot be locked down with a definite QoS and Bandwidth if the ownership is not at the static side driver.

The IP integrator provides the NoC INI strategy option Auto where it automatically fixes the strategy to the legal value. For a NoC INI based DFX boundary path where master is in the static region, the user can select NoC INI strategy in static region to be Auto. This is the default option. IP integrator during validation will automatically compute INI strategy to the right value.

Static NoC Slave can be Driven by only 1 RP When the NoC Path is Owned by RP

NoC DFX DRC

[BD 41-2480] NoC DFX Rule: Static NoC slave can connect to at most one RP 
where the noc master owns the path (INI strategy=load). NoC Slave (axi master) 
/static_region/axi_noc_1/M00_AXI connects to >1 RP that owns noc paths:  
/rp1/axi_noc_2/S00_AXI 
/rp2/axi_noc_3/S00_AXI. To fix: Only have one RP drive the NoC slave 

Reason

Reconfigurable Partitions may be configured with different reconfigurable modules. When there are multiple reconfigurable partitions in a design, both the RPs can be swapped independently. Hence, for a NoC Path between static and RM, if the NoC slave is in the static region and the RM owns the path, then the path must be owned by only one RM. Multiple RPs cannot take the ownership of a single NoC path.

Solution

You may encounter the above situation when NoC INI strategy of NMU in RPs and NSU in static region of that boundary path is set to Single Load, Driver (NMU) owns the DFX path and has QoS. A solution is to keep the path ownership of path to NMU in DFX region by adding another logical NoC in Static region: Add a new logical NoC in the Static Region and separate the boundary NoC path into two separate parallel boundary NoC paths from RPs to Static region.

NoC Endpoints in the RP Boundary can Connect to Only One Type of INI Strategy

NoC DFX DRC

[BD 41-2477] NoC DFX Rule: NoC Endpoints can only connect to one type of 
INI strategy (either driver or load, but not both) at the RP boundary. NoC Slave (axi master) 
/static_region/axi_noc_3/M00_AXI has both INI strategy load /rp2/M01_INI_0 and 
INI strategy driver /rp2/M00_INI. 

Reason

Each reconfigurable partition is expected to be Out of Context synthesized independently. When they are stitched together at the top level, they should have matching boundary pins. The boundary should meet the NoC rules with respect to Driver and Load. This is more critical when both NMU and NSU are in different reconfigurable partitions where respective OOC synthesis might not be aware of the NoC INI strategy of the other RP. Because of this reason, recommendation is to keep all INIs of NoC at the boundary of the RP to be of same strategy. This also helps to prevent duplicate paths of NoC which is illegal in DFX design.

Solution

Recommendation is to keep all INIs of the NoC at the boundary inside RP to be of same strategy. With this, the ownership of the boundary path can be handed over to the NoC outside the RP. If all the RPs’ boundary NoC’s INI keeps the same strategy, after stitching back individual OOC RPs, the INI strategy of AXI NoC in the static will own these boundary paths. This is recommended as QoS of the boundary paths will be locked down by the static region NoC.

NoC Endpoint can be Exported Only Once Across a DFX Boundary

DRC for NMU ERROR

[BD 41-2577] NoC DFX Rule: A NoC endpoint can only be exported once across a DFX boundary.
This means a NoC Master can only have one INI with strategy=driver crossing a DFX boundary. 
NoC Master (AXI slave) /h1/axis_noc_0/S00_AXIS has 
the following strategy=driver INIs crossing a DFX boundary: /axis_noc_1/S01_INIS /axis_noc_1/S00_INIS

DRC for NSU ERROR

[41-2577] NoC DFX Rule: A NoC endpoint can only be exported once across a DFX boundary. 
This means a NoC Slave can only have one INI with strategy=load crossing a DFX boundary. 
NoC Slave (AXI master) /h2/axis_noc_1/M00_AXIS has the following strategy=load 
INIs crossing a DFX boundary: /axis_noc_0/M00_INIS/axis_noc_0/M01_INIS

Reason

For a boundary NoC path between Static and RP, For NSU, there can be only one INI with strategy Single Load, Driver (NMU) owns the DFX path. For NMU, there can be only one INI with strategy Single Driver, Load (NSU) owns the DFX path.

If there are more than 1 INI with (strategy = Load for the NSU) or (strategy = Driver for the NMU) in boundary path, it means the path from NMU to the specific NSU is coming through multiple NoC INI endpoints. This is not allowed in the DFX design because In DFX flow, you must lock down the boundary path with one unique INI endpoint to NSU that later iterations of the RMs can use. One conceptual model is to consider that for strategy=load, the load (NSU/MC) is exported at the RM boundary, and likewise for strategy=driver, the driver (NMU) is exported at the RM boundary. The endpoint can only be exported once.

Solution

Ensure that an INI path crosses the RM boundary only once.

A Reconfigurable Partition cannot have a NoC passthrough

NoC DFX DRC

[BD 41-2476] NoC DFX Rule: An RP cannot have a NoC passthrough. 
Path across '/r4_mid' from /r4_mid/S00_INI_0 to /r4_mid/M00_INI_0 is a passthrough. 
To fix: Ensure an RP has a noc endpoint. 

Reason

To avoid NoC path issues when reconfiguring an RM with a passthrough, passthroughs in an RM are not allowed. Please note that a NoC passthrough is allowed in the static.

Solution

If you are not expecting to have any NoC Endpoints in the reconfigurable partition for a boundary NoC path, you should not keep a passthrough of NoC path through RP. However, if you are planning to reserve a NoC path in the reconfigurable partition for future RM iterations, you should also add a NoC endpoint in the RM in the first implementation itself as a place holder.

NoC Path between Multiple RPs should have Static Logical NoC Instance

NoC DFX DRC

[BD 41-2478] NoC DFX Rule: NoC path between two RPs must be static. 
Path from /r5_rp1/axi_noc_0/S00_AXI to /r5_rp2/axi_noc_1/M00_AXI is not owned by the static (or parent). 
It is owned by /r5_rp1. To fix: add a noc instance in the static to connect this path, 
and have it own the path by setting the input INI strategy to driver, and the output INI strategy to load. 

Reason

In this case there is an NMU in one RP connected through a passthrough in the static to a NSU in another RP. The static must own the NoC path. Each RP can be reconfigured independently and the NoC path between them must be static so it can remain valid regardless of the configuration of each RP.

NoC paths that communicate between multiple RPs should have static logical NoC instances. Otherwise it is not possible to lock down the NoC path with a specific requirement. Since both RPs can be independently OOC synthesized, it is possible to create a final NoC solution which may be not compatible. Hence it is critical to have a Static endpoint for all NoC paths that communicate between RPs.

Solution

Configure the a NoC pass-through in the static so it owns the path, by having the INI input with strategy=driver and the INI output with strategy=load.

Static NSU/MC driven by an RM must have an NMU in the RM

NoC DFX DRC

[BD-41-2616]: Static NSU/MC should be driven by an NMU in the RM.

Reason

The tool requires a complete NoC Path for NoC configuration and validation. This error should not be seen because the tool will auto-add a NoC NMU when needed. During design development, you can have a NoC with a non-driven INI output, where that output exits the RM and drives a static NSU/MC. In this case the NoC with the non-driven INI output will auto-add a stub NMU to complete the NoC path. It is not legal to have an INI external output port that is not driven.

Solution

Even if a specific reconfigurable module does not use that specific NoC to talk to static region, it is recommended to add a place holder NoC NMU in each RM so that each NoC path is complete and tool can successfully perform NoC validation.

Active RM must exercise full set of NoC INI connections

NoC DFX DRC

ERROR: [BD 41-2325] The NoC INI interface can only connect to noc IPs. The following pins on non-NoC IPs are connected to INI. These must be disconnected, or if connected to a BDC external port, a NoC must be added in the BDC to connect to the INI port:
/rp1/S00_INI

Reason

Validate Design uses active BD sources while performing design rule checks. In this scenario the NoC path is owned by the static. The implementation flow requires that the static plus the default RM (RM implemented with the static in the parent configuration) MUST implement this NoC path (the NSU/MC must exist in the default RM) to ensure the NoC path is configured for subsequent RMs to be able to connect to it. The hardware does not require the initial configuration of the device to contain the full complement of INI connections to program the NSU/MC as the NoC path is still there as part of the static design image.

Solution

Modify the active RM to fully populate the set of NoC INI interfaces to ensure complete usage by changing the block design container to point to a BD design source that does meet this condition. Then ensure the parent configuration uses an RM instance that contains the full complement of NSU/MC connections needed.