Constraints Development on a modern SoC takes several months and requires many iterations of backend flows in order to converge on a set of "meetable" constraints that will result in silicon success. Our customers tell us that anywhere from 60% to 90% of their "timing debug" cycle is spent locating and fixing constraint issues, with the remainder spent either analyzing physical closure issues or looking for potential point-to-point exceptions to ease timing closure.
That 60-90% represents the biggest single improvement that could be made in the constraint development cycle both to the productivity of Timing Engineers, as well as to the 10s to 100s of implementation engineers per-team that are dependent on good constraints from Timing Engineers to make quick, meaningful progress and tapeout working silicon on-schedule.
Timevision is specifically designed to address this need, massively accelerating the 60-90% problem, and derisking schedules significantly.
Understanding Design Intent
Timevision has a variety of proprietary features to understand design intent automatically, without designer specification, to massively reduce the noise and complexity in constraint analysis. This also enables Timevision to solve some of the biggest problems in constraint analysis - interclock exceptions - without requiring any designer input to achieve a fully valid & complete constraint generation or check.
Integration of IP
IP comes in many forms these days - internal, external, hard, soft, netlist-only. Most SOCs are now comprised largely of either reused internal IP, or external IP. The key salient feature of IP is it's ability to allow the designer to move up the abstraction layer - and generate system functionality quickly using pre-written and pre-verified functional pieces.
However, integrating IP into the SOC becomes a big problem. Constraints written in isolation for the IP are typically not portable into the system level context. STA engineers rewrite them at the chip level - but there is always the question of whether the "new" constraints are consistent with the provided constraints for the IP. Addtionally, many IP blocks can be configured in multiple ways that impact timing - and understanding these configurations quickly, before expensive implementation iterations occur, is a key to rapid closure.
Integrating tools that affect constraint signoff
Many tools impact the ability for constraints to be "signed off" as golden. CDC tools are required to formally validate false paths between clocks and between registers. Back-annotated simulation is needed to catch incorrect exceptions that result in regression failures. Property checkers are needed to formally verify certain styles of exceptions.
What's missing is an integrated way to bring all these technologies together, and have them perform in concert, with extremely short runtimes, to enable RTL and STA engineers to make immediate, sound judgements about design timing.
Timevision is designed to meet this requirement.
Moving up the Abstraction Level
One factor impacting the ability of "big SOCs" to be successfully prototyped and implemented is the difficulty of producing accurate constraints early on in the cycle - often, RTL and system architects are not familiar with the intricacies of constraint development. By moving up the abstraction level, and defining simple system-level properties that define the design as a "golden" starting point for constraint development (allowing a complete constraint set to be immediately and accurately synthesized), early feasability experiments can be performed, and accurate starting points for implementation flows are readily available.
Constraints and Low-Power
One common approach to constraint development is to define all clocks at nominal frequencies, put no exceptions in at all, and start implementation - and add in what is reqired to meet timing. This results in a completely minimal set of interclock & other exceptions, and is seemingly an ultra-low risk way to get working silicon. However, leaving false-but-meetable interclock paths in the design results in excessive strain on the implemetation/optimization flow - adding significant power to the design, both through optimization of dont-care logic as well as making implementation work even harder in do-care situations.
Focusing the tools only on "true" logical paths required for working silicon leads to faster implementation cycles, lower area and lower power.
Limitations of Linters
Many products in this market are fundamentally Lint'ers. They have a database of rules which they check against designs, looking for and reporting rule violations. Rule violations can be waived, and debug facilities are needed for determining the source of the rule violation.
Linters are an important part of the design engineers' arsenal of technology, but do little to address the real problem in constraints development. In a design with 10 000's of IO ports, 10s to 100s of no/lo-documented IP blocks, and 100s of clocks, a linting tool will produce reams of data on anything other than a perfect set of constraints - which could still be wrong. Designers in this environment require a higher-order, automated view of constraint development that enables them to make rapid progress towards a fully qualified set of timing constraints.