FONT SIZE : AAA
Analysis of the implementation results for an SSI design is largely similar to that of a monolithic. There are no additional steps or reports to create; however, some of the existing reports will show additional information pertaining to SSI. When generating a utilization report for instance, a few additional sections appear for an SSI device that contains useful information about the implementation run. The fifi rst two SSI-specififi c sections contain information about the SLR crossing and clocking.
This is a good indicator of how well the design is partitioned in the device. Looking at the total SLL s and usage percentage ensures that they are within the expectations and goals for the design. Analyze the clocking to ensure that it is distributed as anticipated. Within the SLR connectivity matrix section, the more interesting information is concerning the number of signals that must cross multiple SLRs, SLR0 to/from SLR2 for instance. While it is many times impossible to get that number to zero, keeping that number as low as possible is a good indicator of a well-portioned design. The remaining sections more pertain to SLR resource utilization statistics:
These sections indicate whether per-SLR utilization goals are met as well showing the balance of resources across the different SLRs. You need to consider changes if a particular resource appears to be close to full utilization in a given SLR that can impact placement, timing, or future design growth.
Timing reports are another place where SSI-specififi c information can be found that is important to understand in terms of analyzing the results of the implementation run. When analyzing any failing path, look whether the data path crosses one or more SLRs. This is clearly denoted in that section of the report with an SLR crossing notation followed by the originating and destination SLR numbers. If this indicates that more than one SLR is traversed, timing will be diffifi cult to meet for that path. If there are several logic levels or a very high fanout, net is created on an SLR crossing that may make it diffifi cult to meet timing. If any of these situations are encountered, the more common approach to address the timing issue is to either change the logic in the failed timing path to reduce depth/fanout, repartition the logic to reduce SLR crossings, or add additional pipelining .
For high-speed logic paths that must cross SLRs, clock skew and clock uncertainty due to inter-SLR compensation should also be analyzed for improvement. Due to the size of SSI devices, clock skew can be a larger impact to timing than in smaller devices. First you want to ensure that a good clocking topology is used incorporating proper clock buffer usage and no logic exists in the clock tree as poor clock management impacts can be magnififi ed in these larger designs. When crossing SLRs, it is generally best to not at the same time cross common clock domains as well as that can introduce additional clock skew to the timing path. Inter- SLR compensation is a calculation applied to timing paths that the source and destination exist in separate SLRs to account for uncertainties in the clocking due to PVT (process, voltage, and temperature) differences between two SLRs. Minimizing clock skew as well as the distance traveled and thus insertion delay between points crossing the SLR are ways to better manage the impact of inter-SLR compensation.
A true benefifi t to the manual partitioning approach is that, if done properly, any critical timing paths found after place and route are typically contained within an SLR, and general timing closure techniques can be applied to address them. It is also often found that, once functional and timing closure is completed on an SLR, logic changes to other areas of the design have little to no impact on that portion of the design. This can be less true for general monolithic or automatically partitioned design strategies.
Manufacturer:Xilinx
Product Categories:
Lifecycle:Any -
RoHS:
Manufacturer:Xilinx
Product Categories: FPGAs (Field Programmable Gate Array)
Lifecycle:Active Active
RoHS:
Manufacturer:Xilinx
Product Categories: FPGAs
Lifecycle:Obsolete -
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories:
Lifecycle:Obsolete -
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories:
Lifecycle:Obsolete -
RoHS:
Support
