NoC Paths must be Owned by Static if they have a Static NMU.
[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 decide 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 static region, 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.Note: Automatic computation of NoC INI strategy is currently supported only for top BDs and not for child BDCs, unless the child BD’s strategy can be determined unambiguously due to either multiple drivers or multiple loads within the child BD.
Static NoC Slave can be Driven by only 1 RP When the NoC Path is Wwned by RP
[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 are may hit 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
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 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
[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=driverand the INI output with
Static NSU/MC must be 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 the RP so that NoC path is complete and tool can do NoC validation.