Timing Closure with Design Assistant

A quick look at the Timing Closure rules available in Design Assistant that will help you find timing violations and get to closure faster.


Hello. My name is [INAUDIBLE], and I'm an application engineer for Intel [? SPG. ?] In this video, I'll be showing you how to use the Design Assistant feature for timing closure.

Before we begin, let's have a quick recap on how Design Assistant works. When enabled, it reports any violations against a set of recommended design rules, also known as DRCs. This helps to increase productivity, by reducing the total number of design iterations for design closure.

While Design Assistant comes with rules from multiple categories, such as clock, linting, and floor-planning, this video will focus particularly on timing-closure-related rules, or in other words, specific violations that cause timing violations in your design.

We now have timing closure rules which are intuitive, in the sense that first, your design will be checked if it has a bad topology based on the selected DRC rules. Next, the tool will look at the top 1,000 setup violated paths. If these two conditions are violated, only then the design system violations will be reported to the user. What this means is that there will be less false positive, because we are only getting the violations that cause timing failures in our design. In other words, there be no rule violations for the portions of the design that pass timing.

To enable these rules, simply filter the rule names by the alphanumeric ID that begins with TMC-202.

Now, let me walk you through an example. In the conventional timing closure flow, we will first look at the Timing Analyzer Report panel to determine if the [? design ?] is timing. If there are any timing failures in the design, we will then launch the Timing Analyzer GUI in order to get more information and details on the failing path.

In this example, the design is failing timing because the source node, which is a RAM block, has a [INAUDIBLE] value. This suggests that the output of the RAM might be unregistered. To confirm this, we will then [? cross-probe ?] into the [INAUDIBLE] Viewer, and as shown here, the output of the RAM block is indeed not registered.

Notice the numerous steps involved in order to determine the timing bottlenecks involved. A user will need to repeat the same process for a [? differing ?] path, as well.

Now, what if we have a tool that does all the steps mentioned previously in the background and tells us exactly what and where to fix the problems? This is where these timing-closure-related rules that come with the Design Assistant tool become extremely useful.

With the problem now being identified, users can now proceed to fix it-- in this case, registering the output of the RAM block.

What we have seen is just one of the many timing-closure-related rules that are available the Quartus Prime Pro software, so go ahead and try out other rules, as well.

To wrap up, let's summarize what we have learned in this video. With the introduction of timing-closure-related rules, you can first look at the Design Assistant reports without opening other tools such as the Fast-Forward Recommendation reports or the Timing Analyzer. The Design Assistant reports will let you know what and how to fix, saving you time and effort needed for design closure. Finally, since these reported violations are specific to your design, you can be sure that they are relevant, and hence have less false alarms.

Thank you for watching this video, and I hope you find Design Assistant useful.