The problem with computers is that they have no common sense. They can’t simply do the normal thing in a normal situation, whatever that might be. High in a rarified Manhattan skyscraper, the team of architects bemoaned the brain-deadness of their building design tools. One of the more tech-savvy of the architects noted that it would be so awesome if someone could invent a “common sense” module for computers. You would access it using the “duh” function. Like, “if <condition> then <do the thing I specifically need> else duh()”. In other words, “else do the obvious thing” or “else don’t be a moron.”
Absent such intelligence, they had had to deal with the regrettable fact that a computer will do exactly what you say and nothing that you don’t say (except perhaps some side effects, but only if they’re undesirable). They had thought that using computers would simplify their process of checking construction plans for new houses, and it was actually starting to pay off, but things had gotten worse before they got better.
A good example was in checking to make sure there were deadbolts on all the various entrances. At first they simply made the rule, “Make sure all the doors have deadbolts.” But, of course, then all the internal doors were flagged as missing deadbolts. So they rewrote the rule as “Make sure all doors have deadbolts, but ignore inside doors.” Which mostly worked, except there were some houses with utility closets on the outside that clearly didn’t need deadbolts. So they refined the rule to “Make sure all doors have deadbolts, but ignore inside doors and utility closets.”
This served them well until they had the one guy with the different idea of having a utility closet that he could enter from inside or outside. Now the inside door didn’t have a deadbolt because it was not an outside door, and the outside door didn’t have a deadbolt because it was a utility closet door. And so they had a security hole. After deciding that, in this case, the deadbolt should go on the inside door, and, being careful not to start deadbolting inside-only utility closets, they finally settled on the rule, “Make sure all doors have deadbolts, but ignore inside doors and utility closets except inside doors to utility closets that also have outside doors.”
Up until then, it was actually faster to do the verification by hand. Now that they finally had the thing working, hopefully the computer would start saving them some time.
Designs have rules that have to be followed, and rules have exceptions. Rules might also be requirements; for instance, the requirement that a given signal path have a given delay. And, in the manner of rules, these can also have exceptions.
The two primary exceptions are “false paths” and “multi-cycle paths.” These are paths that don’t need to meet timing requirements (and, in all likelihood, won’t or can’t meet them). You don’t want a synthesis or place-and-route tool wasting effort trying to get those paths to meet timing. And you don’t want the timing analysis tool to fill the report with timing failures that you don’t care about. So you specify these paths as exceptions, which is generally done by creating constraints that specify the exceptions, so that the tool will ignore these paths.
It’s possible to think in terms of a couple kinds of exceptions: those that are done by intent and those that are done by design. If you know that your chip will, for example, have certain tests done at a much lower frequency than the typical operating frequency, then paths that are associated only with those tests can be marked as false, meaning they will be ignored when synthesizing for operating speed. There’s nothing in the design that makes this obvious; it’s only the designer’s brain that knows which paths these are.
There are also paths that, according to the design, make no sense from a standard timing perspective. Two registers, one after the other, with opposite clock polarities or with data select muxes having opposite select polarity, create a situation where the delay between them would actually have extra time before the downstream register would catch the data from the upstream one; this would be a multi-cycle path.
Because many exceptions have such signatures in the design, they can be proven outright as correct or not. This can be a useful thing, because, as you go through your design, marking exceptions, you may over-specify the exceptions so that you’re actually ignoring cases that shouldn’t be ignored. These can show up later as actual silicon bugs.
One solution is to specify your exceptions and then run a tool that verifies them formally. Those exceptions that are evident in the design will obviously pass, but the exceptions that only reflect intent would fail because, on its own, the verification tool has no way of knowing the intent.
And here’s where you start refining your exception specification. You can say that, under certain conditions, a path is false; or perhaps specify that, during a particular verification run, assume that certain external signals have a particular constant value that, for example, disables test circuitry. You can add variables that turn on or off bits of behavior for certain verification runs. By refining the exceptions more precisely, you end up encoding your intent in the exception, and the tool can now verify that the exception is valid only for those conditions where it should be valid.
Real Intent has been the incumbent in this space for several years, using formal methods to accomplish a number of different specific verification tasks. Their PureTime tool provides constraint and exception verification. While focusing on the gate level in the past, their version 3.2 release in August added the capability of verifying exceptions at the RTL level, which allows verification at the same level of abstraction as the design. They also provided more focus on verification and reporting for the exceptions themselves, in addition to the paths specified in the exceptions. And they added debugging capabilities for locating problems either in the exception definitions (typically SDC files or TCL scripts) or the design sources.
There’s a newcomer in this arena, however, a company with the picturesque name of Fishtail. They have a Confirm product that will validate exceptions that the user creates. But this is actually only one of a three-piece suite of tools.
If certain exceptions have a signature in the design that can be validated, then it stands to reason that those same exceptions could be automatically extracted from the design. This is the role of Fishtail’s Focus product. They have (at present) four different kinds of false path and one type of multi-cycle path that they can recognize and create exceptions for:
When a source and capture register for a path have two different clocks, a clock-to-clock false path is created.
- When a source and capture register have a muxed clock source such that only one clock is active on the design at a given time (and subject to other conditions more detailed than I’ll mention here), a clock-to-clock false path is created.
- If a path from one register to another cannot be sensitized, a register-to-register false path is created.
- If a path between two registers can be sensitized only when in an unreachable state, a register-to-register false path is created.
- If clock or data muxing on the source and capture registers of a path are such that the sourced signal could not be captured on the next cycle, a multi-cycle path is created.
They also used to generate multi-cycle paths for registers with mutually asynchronous clock rates, but it became clear that inferring this (in the absence of one clock being generated from the other in the design) didn’t make sense; it was much easier just to have the user specify the actual clock rates. So here’s an example of an exception that got moved from being considered a by-design exception to being a by-intent exception.
These two tools, then, provide you with a combination of exceptions, those automatically generated with Focus and those created by the user and verified through Confirm.
There’s one more piece they provide to help manage the design flow. As the design gets processed from RTL to gate level and beyond, changes occur each step of the way. Those changes may be as trivial as signals being renamed, but, as anyone who has tried to do anything remotely creative in the EDA space knows, renamed signals can torpedo the most innovative ideas. So Fishtail provides a tool called Refocus that can be used to keep the exceptions, as well as other timing constraints, in synch with the design each step of the way, resolving names and hierarchy and other issues so that, ultimately, constraints can be used at any level and issues and debugging can be managed at the RTL level.
Both Real Intent and Fishtail will point to various advantages of their respective tools beyond just the high-level features described here, but I’ll let them be the bearers of those messages and let them duke it out for themselves.
Of course, the need for all of these precise exceptions arises ultimately out of the failure of the engineering world to devise a common sense module that EDA tools can use. Once we’ve got that, these kinds of verification tools won’t be needed anymore. We’ll be the first to let you know when that happens.
Don’t wait up for it.
Links:
