|
|
|
|
||
|
||
|
|
||
 |
Timing Analysis/TW FAQ SheetThe following subjects are included in this FAQ and will be updated as new subjects are added:Understanding the TWR Data Sheet Section numbers How does the Clock to Setup table deal with DLLs? What's the deal with case sensitivity in constraints? How are Hold Checks performed and how do I interpret the TWR? What about Virtex IO Setup/Hold times? What does it mean if an OFFSET IN BEFORE
reports a negative slack?
Understanding the TWR Data Sheet Section numbersSoftware will report the guaranteed pin-to-pin numbers for any architecture that has them in their speedfiles. Version 3.1i includes 4kxla, SpartanXL, Virtex and Virtex-E.The Data Sheet section numbers are created from a timing analysis against constraints. Be aware that we only report the Data Sheet timing numbers for paths covered by constraints. This means that we will only provide numbers for IOs covered by OFFSETs (global, group, net) constraints in the PCF, we won't report any IO Pad to Setup, Hold, or Clock to Out specs in the Datasheet report. The -u (unconstrained paths) switch will pick up any unconstrained IOs or the use of Advanced Analysis (Auto-generated constraints) or default analysis will pick up the IO timing. An oddity in our system causes paths in FROM/TO constraints for Pad to Setup to be shown in the Datasheet section, while FROM/TO for Clock to Pad are not. For CLB flops, the datasheet setup/hold numbers make it pretty obvious that we are not using a 70% rule, but should. Often the two numbers only differ by .5 ns, seemingly too small of a data invalid window. We will be prorating clock paths for setups, and data paths for holds, in the August update to 3.1i. Until then, if customers want the most conservative setup and hold numbers for Pad to CLB register setups, they should prorate on their own. We do not yet report a faster than guaranteed number, if one exists. That remains a future enhancement. How does the Clock to Setup table deal with DLLs?The Data Sheet section for Clock to Setup by clock destination reports clock information by clock pad. This means that for clocks that are distributed by a DLL are reported by only the clock pad. For example, if you have a clock (clk) that drives the clk_in of a DLL and the DLL outputs both 0 phase (clk0) and div2 (clkdiv2) clocks, the table in the Data Sheet will include all information from those two distributed clocks. Lets say "clk" has a period of 10 ns (50% duty cycle) and "clkdiv2" has a rising to falling minimum of 8 ns. The 8 ns half cycle is fine as that is less than half of the clkdiv2 period, but it shows up in the Data Sheet section as 8 ns in the clk Clock to Setup table, which looks like a violation of the 10 ns half cycle value of 5ns. The same will be true of a rising to rising value for clkdiv2 which can be twice as large as the clk requirement.What is Kpaths?Kpaths is a non-enumerative method to performing static timing analysis on a circuit. The previous Depth First Search (DFS) algorithm was used to perform enumerative analysis of all circuit paths in a design, which can be computationally expensive for designs with many circuit paths. While K-paths derives it's name from the algorithm which can be used to only enumerate and calculate the critical paths, we use it to cover all paths. It saves significant amounts of runtime because it only has to trace twice through any given node in the design, where previously we would trace through a node once for every endpoint it eventually went to. I would also say that it was introduced selectively in 1.5, became the default-timing algorithm in 2.1i, and is now the only algorithm available in 3.1i.My coverage is less than 100%, but I'm sure that all paths in my design are covered. What's going on?
The most common reason for connection coverage not hitting 100% is that elements in the design have TIGs. If the Timing Wizard encounters a TIG'd element when tracing a path, the trace will stop there, possibly leaving connections on the "other side" of the element uncovered. A path TIG (FROM TO TIG) on the other hand will have all of its connections accounted for in the coverage statistic. There are less obvious reasons for less than 100% coverage. One is that the total number of connections in a design includes some which cannot be covered by constraints. An example is the connections on the STARTUP component. Another example is the case where a static pin drives a LUT, which combines with no other signals and then drives other logic. This can happen at the start of a carry chain where a FORCE (1 or 0) is used. Also if terms for carry logic are connected to a CLB, but go unused within the CLB, these connections will never be traced. These are obscure cases which aren't handled well, but in all cases they are uninteresting for timing analysis. Obviously there will be cases where a bug in either the speed files or, less commonly, the code results in a coverage statistic does not meet 100%. Note that if a default analysis is run with no PCF file you can get 100% connection coverage even in these odd cases. This is because when doing the net analysis, an instantiation of every connection in the design is made to analyze the delay for each driver/load combination. There is simply no way to get path coverage for these odd cases in the existing code. A quick explanation for the reason these situations arise is that determining the total number of connections in a design is a simple operation, while making a determination of how many of those connections are valid for timing analysis is much more expensive in analysis time. We will continue to consider ways to decrease the confusion surrounding the coverage statistic as time permits. What's the deal with case sensitivity in constraints?The basis of the software, the old NeoCAD Foundry, was case sensitive for almost all applications since it's inception. XACT was case insensitive in most cases and thus the initial merge of the two systems confounded many people who were used to the previous behavior. As a result some of the case insensitive features of XACT have been carried over, but by no means are all cases changed. Known places where there are inconsistencies in searching mechanisms across the software include the fact that case insensitive name matching can be carried out in NGDBUILD, while downstream tools such as Timing Analyzer do not do so.What is clock skew?In M1.4 and later, the Timing Wizard supports path delay analysis that accounts for clock skew. The clock skew is added to the calculated data path delay to arrive at a total path delay which is compared to the constraint (or reported as the delay for the path when the constraint has no value). Note that skew is only accounted for when it works against the constraint and is truncated to zero if the reverse is true.How are Hold Checks performed and how do I interpret the TWR?When are hold checks performed?Hold checks are run for all clocks on global resources automatically. For local resource clocks, the TRCE -skew switch or the TA (Perform Hold/Race Checks checkbox). Virtex low skew resources are automatically evaluated in 3.1i if the USELOWSKEWLINES constraint were specified and were evaluated if the MAXSKEW constraint was used in 2.1i tools. The -skew switch picks up the low skew resources in either release.
How does skew relate to hold/race check functionality?Hold/Race checks are done on register to register paths by taking the data path (Tcko+Troute_total+Tlogic_total), subtract the clock skew (Tdest_clk - Tsrc_clk) and the register hold delay (Th). In the TWR report , it uses slack to evaluate the hold check. Negative slack indicates a race condition, positive slack means there is no race condition. Below is the equation for hold slack calculations:Hold Slack = Tdata - Tskew - Th The detailed path will be reported under the constraint that contains that data path. The path will be listed by the slack with respect to the requirement. There will be no identifier of the hold path except the delay type. This will be changed somewhat in Dolomite, as a (-Th) will appear after the hold delay type to help identify race conditions. This doesn't make much sense and we are looking into fixing this in the Emerald release. What does the hold violation look like in the TWR report?TWR reports hold paths only if there is a race violation. Note that the setup details for a specific path will not show up if there is a race violation as TRCE can only report the path once. The clock skew is reported in the path header, but the delays to the source clock pin and destination clock pin is not included. These can be determined by going into TA and using the "Analyze Against User Specified Paths ... by defining Endpoints...". Specify the clock pad input as the source and specific or all registers. This will give you the clock delay from the pad to each register clock pin. This will work for DLL paths also. Subtract the destination clock delay from the source clock delay to get the clock skew. Paths under a constraint are always sorted by slack. Race violations are designated as negative slack and are sorted with the setup violations also represented in slack (Tsu slack = Constraint_requirement - Tneg_clock_skew - Tdata_path - Tsu). The delay value for the hold of the register is presented in the detailed section of the path. To get the slack value at the beginning of the path, take the clock skew and subtract the total delay from the detailed portion.Hold Check IssuesWhen hold checks are performed, the data path is not adjusted to show possible variances in the PVT across the silicon. Generally, you will not see race violations as you need a very short data path and a large clock skew to get this problem.The hold slack doesn't relate to the constraint requirement and may be confusing when looking at the slack and the minimum delay/period for the constraint. Only the slack from setup paths affect the minimum delay/period for the constraint. We could account for clock skew regardless of the resources used for the clocks, but it can lead to problematic behavior within PAR. The current protocol between PAR and the Timing engine does not support a means to minimize skew, nor can it maximize a clock delay for a specified data path. This means that PAR could change the placement and think it was minimizing the path delay, but end up exacerbating the problem by changing the skew. The result is that PAR can never converge on a good timing score. For PERIOD constraints the skew checking works as outlined above. However if there is a Two-phase condition, the tools will incorrectly calculate race conditions based upon the clock edges being in phase. A Two-phase path is clocked between opposite clock edges (rising to falling or falling to rising). If the constraint is a FROM/TO it is assumed that the user has accounted for, within the value of the constraint, any known external skew between the clock sources if the endpoint registers do not share a common clock. If the registers share any single common clock source, the skew is only calculated for the common clock sources. If no common clock source points are found the skew is the difference between the maximum and minimum clock paths. Gated clock networks cause the skew checking code to perform a lot more work than simple, single logic level clocks. Skew checking will work within default analysis, unconstrained FROM/TO constraints, Advanced Analysis, and the unconstrained paths (-u) report. If race conditions are detected they are reported as errors at the top of the report. 2.1i specificsThe detailed path report is adding the hold delay time to get the path total when in fact it should be subtracting the value. The column total is wrong, but the number in the header is correct, therefore the check is valid. This is fixed in 3.1i.3.1i specificsThe TWR report now indicates a (-Th) after the hold delay symbol (i.e. Tckdi) in the detailed section of the report. This has two purposes, first it identifies the path as showing a hold violation more clearly than just the delay type, second the minus indicates that the number to the right is to be subtracted from the other path values. In many cases the hold delay is negative and therefore will be added (subtracting a negative number).What about Virtex IO Setup/Hold times?In DQA, TRCE will start to adjust the clock and data paths for setup and hold checks.What does mean?When TRCE is evaluating a data path from an IO to a register, it will adjust the paths as follows:Setup checks will adjust the clock path delay by a factor that is determined by the clock distribution type. Three different clock distribution types exist, global, low skew resources and local resources. Hold checks will adjust the data path by a set factor for all paths. When a setup check is performed, the slack calculations will use the factored clock and a max data path. When a hold check is performed, the slack calculation will use the factored data path and the max clock path. Why is this being done?This is being changed to more accurately reflect the setup and hold times calculated for a design as clock speeds have gotten to the point where the checks may or may not flag violations.Why not do the register to register paths this way?At this point the numbers for the register to register paths are accurate enough to necessitate investing the development time to use this. As clock speeds increase, this will become more of an issue.What does it mean if an OFFSET IN BEFORE reports a negative slack?A negative slack for a path under an OFFSET IN BEFORE indicates that the data path is shorter than the clock path and that a race condition may exist. Please be aware of this issue. |
 
|
   |
|||||
|
| Home | Products | Support | Education | Purchase | Contact | Search | | |||||