Design Constraints (Sdc) By Sridhar Gangadharan, Sanjay Churiwala pdf download. Synthesis And Timing Analysis: A Practical Guide To Synopsys Design. 1. Sequential Clocking. 2. Static Timing. Analysis. 3. Design Constraints. 4. Timing Reports . Exhaustive, i.e., every (constrained) timing path is checked. .. But during synthesis, we assume the clock is ideal, so: • However, for realistic timing. This book serves as a hands-on guide to timing constraints in integrated circuit design. Readers will learn to maximize performance of their IC designs.
|Language:||English, Spanish, French|
|ePub File Size:||20.59 MB|
|PDF File Size:||15.61 MB|
|Distribution:||Free* [*Regsitration Required]|
Sridhar Gangadharan · Sanjay Churiwala Constraining Designs for Synthesis and Timing Analysis A Practical Guide to Synopsys Design Constraints (SDC). Constraining Designs for Synthesis and Timing Analysis. A Practical Guide to Synopsys Design Constraints (SDC). Authors Sridhar Gangadharan, Sanjay Churiwala. Pages PDF · Synthesis Basics Timing Analysis and Constraints . The book Constraining Designs for Synthesis and Timing Analysis: A practical guide to Synopsys. Design Constraints (SDC) written by Sridhar.
I dedicate this book to them. Clock name plays a very important role in SDC. A setup check would be made even at outputs. Even for gate level, as the design progresses further into the flow, the estimates for routing delays and capacitive load become more accurate, which allows for better delay computation and so more accurate STA. Advertisement Hide. For example, for the block B1, the constraints have to be specified to define its inter- action with primary inputs for the design as well as its interaction with other blocks B2 and B4. Period 2.
Thanks to them for showing this faith in me. And, last but the most important one, we would remain indebted to our families and friends. Their cooperation and good wishes kept us going. And, the younger daughter Lubha Churiwala — Std.
VI also helped me with sets of random reviews for Grammar and consistency: I would like to acknowledge a number of people who have helped me. First, I would like to thank God for this opportunity. Thanks to my parents for all the sacrifices they made to educate me and for being a constant source of inspiration and encouragement. I dedicate this book to them. I would also like to thank my wife Bulbul and my son Pratyush for supporting me in spite of all the time it took me away from them.
I would like to thank my mentor Dr. Bose initiated me into the world of EDA 21 years ago and has been a guiding light for a significant part of my career. I would also like to thank my supervisor, Mo Movahed for his support and suggestions while I was writing this book. I would like to express my sincere gratitude to Mike Gianfagna for going out of his way to help me with contracts, proofreading, and providing access to all necessary resources.
Thank you, Ameesh. I know you are up in heaven, smiling down on me. I was very fortunate to have a stellar group of reviewers from the EDA and semiconductor industry who have helped in making the content of the book robust. I am grateful to Fred Revenu Xilinx for writing the chapter on Xilinx extensions. I would also like to thank Charu Puri for helping me with all the illustrations in this book.
I would like to acknowledge my dearest friend S. My apologies if I missed anyone. Thanks to Sanjay for agreeing to partner with me on this book, and thanks to Springer for publishing this book. Last but not the least, I would like to thank Synopsys, Inc. I hope you find this book useful. Xilinx Extensions to SDC In the early days of chip design, ASICs were a few thousand gates.
These are called SoCs or system on a chip. This complex nature of ASIC development requires a well-structured design flow that is scalable and provides enough flexibility to designers and SoC integrators alike to define a methodology for seamless design. It also covers how timing constraints impact these flows. Logical design begins with high-level design specification and chip architecture. The chip architect captures high-level functional, power how much power should the design consume and timing at what speed should the design operate requirements.
This is S. Gangadharan and S. Commonly referred to as RTL register transfer level , this provides an abstraction of the functional behavior of the circuit in terms of how the logical operations on signals enable data to flow between registers flops in a design. Once the functionality of the design is coded, it is verified using simulation. Simulation is a pro- cess where various stimuli are applied to a representation of a design and the response of the design is captured.
The objective is to validate that the resulting output matches the desired functionality of the circuit.
For example, if you implement an adder, which includes two inputs and one output, the test vector will emulate inputs as two numbers that need to be added, and output should represent the sum of these numbers. At this stage, the design is ready for synthesis. Synthesis aka logic synthesis is the step where RTL description is translated to a gate-level representation which is a hardware equivalent implementation of the func- tionality described in the HDL.
Let us consider the following description in Verilog: An HDL description is said to be synthesizable RTL, if it can be consumed by industry standard synthesis tools to map to a unique and unambiguous implementation. In this step, the designer also captures certain design and timing characteristics which are representative of the high-level objectives set forth by the chip architect, like clock frequency, delays available in the block, and target library, so that the synthesis tool can optimize the design to meet the require- ments.
Details on synthesis are available in Chap. After synthesis, the design is prepared for testability. One such technique is called scan insertion, also known as test-point insertion.
Let us consider the circuit in Fig. In this circuit the second flop is not controllable. However, by inserting the multi- plexer structure, the user can control the second flop via a scan clock and scan enable. This results in all registers to be linked in a chain called the scan chain or the scan path.
Similar to clock control, the data to the flop can also be controlled using the scan enable. This is used to test that data can be shifted through the design. This technique helps to make all registers in the design controllable and observable via the inputs and outputs of the design. This is called equivalence checking and uses formal verification techniques. At this stage design is also ready for STA or static timing analysis.
It is worthwhile to note that equivalence checking only verifies the functionality of the implemented gate-level representation against the original description but not whether it meets the frequency target of the implementation, which is the responsibility of STA.
STA is a method of checking the ability of the design to meet the intended timing requirements, statically without the need for simulation. Most STA engines require the designers to specify timing constraints that model how the chip needs to be characterized at its periphery and what assumption to make inside the design so as to meet the timing requirements set forth by the chip architect. This is specified using an industry standard format called SDC Synopsys Design Constraints which forms the premise of this book.
Details on STA are available in Chap. STA step completes the logical design step and acts as the bridge between logical and physical design. Physical design begins with floor planning.
After preliminary timing analysis, the logical blocks of the design are placed with the aim of optimizing area, aspect ratio, and how signals between the blocks interact. These factors have direct impact on power, area, timing, and perfor- mance.
Once the optimal floor plan is achieved, the connections between blocks are routed. During the synthesis stage, many assumptions are made about clock network since that level of design information is not available until after floor plan.
Floor planning is followed by clock tree synthesis to distribute the clock as evenly as possible so as to reduce clock skew between different parts of the design. This step of floor planning, placement, and routing is called layout of a design.
During the physical design, STA may be done multiple times to perform a more accurate timing analysis as the assumptions made during the initial implementa- tion are gradually solidified. All rules laid out by the foundry where it will be fabricated into a chip are adhered to. The layout matches the netlist generated after synthesis.
This is called LVS or layout versus schematic where the layout is formally verified against the post- synthesis netlist. After layout, design is not guaranteed to meet timing and may require to be tweaked further so as to meet the timing and frequency requirements. GDSII is a geometric representation of the polygons that describe the actual layout of the design with all its connectivity. Figure 1. This has direct correlation to the placement, routing, and timing analysis.
The logic block consists of a LUT or lookup table, which can be used to imple- ment any arbitrary combinational function. The output of the LUT is then registered or connected to the output directly. Tracks, a collection of horizontal and vertical wire segments, run between the logical blocks.
These can be programmed using switch boxes to indicate the actual connectivity between the intersecting horizontal and vertical wires. The HDL is functionally verified using simulation and then synthesized to logic gates.
However, the physical design is vendor dependent. Post synthesis, the netlist is compiled to target FPGA on which it needs to be mapped. This compilation step includes mapping netlist functionality to logic block, placing the logic blocks and routing between the blocks using the tracks available in the target FPGA. Once place and route is complete, the delays of the circuit are generated in SDF standard delay format.
Since simulation is not always exhaustive, accurate static timing analysis is also performed at this stage. Once all the verification is complete, the device is pro- grammed. This is called FPGA prototyping. This includes how well the design adheres to the timing, power, and area objectives set by the architect in addition to meeting all the functional requirements.
Given the complexity of both ASIC and FPGA design flows, it is prudent to establish checks and balances at each stage of the design flow for this measure to prevent any late-stage design changes and ECOs. From a timing perspective, at the architecture stage the architect will assign block budgets which are handed off to block owners. Depending on whether a block is a derivative design or being developed from scratch, the RTL designer will create initial timing constraints or tweak existing ones for synthesis.
This will form the baseline for all runs in the implementation flow and typically includes defining clock frequency and budgets in the subblocks.
This results in an unoptimized netlist with ideal clocks clock with zero delay. Once logic optimization step is completed by the synthesis tool, STA is done. At this stage more accurate timing intent in the form of intra-block delay, clock latency, and clock skew is provided, with objective that design meets all setup and hold requirements and correctly estimates any interconnect delay. During the physical design stage clock assumptions skew and network delays made during logical design get solidified.
Delays can be computed more accurately using the actual parasitics extracted from the real routing. Clock tree synthesis is done to balance the clock tree to reduce any clock skew. If you look at the evolution of chip, timing plays an integral part at each step of the flow.
It is constantly tweaked and verified as the design pro- gresses through the implementation flow. At each step the designer tries to ensure that original timing intent as prescribed by the chip architect is preserved. A signifi- cant duration of physical design cycle is spent on achieving timing closure. Given the strong dependence, designers face many pain points ranging from creation, verification, to validation of timing constraints.
During the logical design step, creation of constraints is an error-prone and iterative process. However, at this stage most designers are concerned about meeting the functional requirements, and timing ends up taking a backseat. Once block-level constraints are created, they need to be validated for correctness. The designers also need to ensure that constraints are in sync with the design. When block design is complete, the design and the constraints are handed off to the subsystem or chip integrator.
The integrators develop their own top-level constraints which have to be consistent with the blocks; otherwise, a block which may have met timing may not function when integrated into the subsystem or chip.
To aggravate problems further, there is knowledge disconnect between RTL design and physical design teams. RTL design teams tend to be less concerned about timing since their objective is to meet the functionality. They have to rely on RTL designer to bless the timing con- straints. This disconnect results in unnecessary iterations having direct impact on time to market.
Most design flows are heavily focused on verifying the correctness of the functionality of the design — represented through RTL.
However, an equal emphasis has traditionally not been given to validation of timing constraints. Timing constraints issue can cause unpredictable design schedule, delay tapeout, increase iterations between logical and physical design teams, and result in late-stage ECOs.
A set of con- straints if not written properly can greatly diminish the ability to reuse the block in future SoCs. Since constraints impact performance of the realized hardware design, the quality of timing constraints has a direct correlation to the quality of silicon.
As we will see in subsequent chapters of this book, the world of constraints is full of very fine-grained nuances. Thus, it is very important to understand and write con- straints which are correct as well as efficient.
Chapter 2 Synthesis Basics Synthesis is the first step in the design process, where timing constraints are used. If we have to realize the gate-level circuit for this counter, it would take a lot of time to draw the Karnaugh map and then realize the logic feed- ing into the D pin of each of the 3 flops which form the counter.
However, it is much faster to write an HDL code, which describes the above functionality. This HDL code can then be taken through a tool, which will create the corresponding netlist.
Synthesis in the context of electronic design means realization of a gate-level netlist to achieve a specific functionality. Besides the specific functionality, the pro- cess of synthesis might also meet certain other requirements, namely, power, fre- quency of operation, etc. Sometimes, there are specialized synthesis tools for specific kinds or portions of circuit, e. These steps are of various kinds, e. Synthesis is the first among the implementation steps.
The following subsections give a few examples of the choices that a synthesis tool might need to make and the basis of the decision. These are all examples of additional information beyond functionality that the synthesis tool needs to be provided through constraints. The first information is the functionality that the realized netlist needs to perform.
This information comes from the HDL description. For a device, obviously functionality is the most important consideration. However, designers have to be also very sensitive to: We want to fit as much functionality into the same unit area as possible. We want to conserve battery power and also reduce junction heating.
We want to get highest possible speed from the device. However, each of the above goals may impact the others and sometimes nega- tively. For example, if we want to get best speed, we will need to have higher drive devices, which will mean higher power and greater area on silicon. So, instead of a designer trying to squeeze out the maximum performance, the designer might want to get just about enough performance that would achieve the purpose and, in the process, save on area and power.
A designer communicates his requirements around area, power, and performance to the synthesis tool through constraints. Any further attempt to improve in any one dimension could worsen the other dimensions.
So constraints are used to tell the synthesis tool — among the many possible implementations possible to realize the same functionality, which should be chosen so that all the three requirements on area, power, and performance are met. One of the simplest realizations of this circuit is as shown in Fig.
However, now imagine that the input d arrives much later than other inputs. So the final evaluation of the circuit has to wait till d arrives and passes through 2 AND gates. On the other hand, there can be an alternative realization of the same func- tionality as shown in Fig. In this circuit, by the time d arrives, the other three signals have already been evaluated, and d has to travel through only one AND gate. Though both circuits perform the same functionality and have similar area 3 AND gates , a designer might prefer Fig.
If instead of d, it was some other signal which was coming much later, then d might be swapped with that late arriving signal. Thus, depending upon the relative arrival time for various inputs feeding into the same combinational logic, the synthesis tool might need to decide which design should be chosen among the available choices — so that the last arriving signals have to cross the minimum number of logic.
Designers use constraints to convey to the synthesis tool about the arrival time of various input signals. Thus, higher drive means output would switch faster and a higher amount of load can be connected. Let us say, a specific input has to drive a huge fanout cone.
But, whether the specific input can drive such a huge cone or not depends upon the driving capability of the signal which is driving the input.
If the signal driving the input cannot drive the load for the whole fanout cone, then the signal would need to be buffered before it can be fed into the huge cone. Figure 2.
However, it does not have the drive strength for that kind of load. Hence, buffering is done on the input, before feeding into the load.
With this buffering, the load that the input has to drive is only 3. Designers need to tell the synthesis tool the driving capability of the external signal which is driving the input so that synthesis tool can decide whether or not to put additional buffers.
And constraints are used to convey information about the drive strength of the external inputs. Synthesis tool will then choose appropriate cells or buffers with the right drive strengths that can drive the load. And constraints are used to convey information about the external load that needs to be driven by the output port.
In fact, one could write a whole book around issues faced during synthesis. This section gives a glimpse of some issues around synthesis related to constraints. These same topics are discussed in much more details in subsequent chapters of the book. The design sizes today are humongous, compared to the sizes of design that synthesis tool can synthesize. Thus, a full design has to be broken into smaller units, called blocks. During synthesis stage, the blocks are created based on logical view of the design, namely, related functionality being put into one block.
This kind of partitioning is called logical partition. A synthesis tool would synthesize one block as a unit. Thus, a synthesis tool can view only a block at any given time, and it does not see how the block interacts with the rest of the design. The outermost rectangular boundary denotes the complete design. Usually, the design would have requirements listed for the whole design.
Because the synthesis tool cannot synthesize the whole design, so the design is partitioned into smaller blocks B1 through B6 , represented by inner smaller rectangles. At any time, synthesis tool views a block. But, the requirements are known for the complete design. These constraints for individual blocks have to be created — based on interaction of the block with all other blocks. For example, for the block B1, the constraints have to be specified to define its inter- action with primary inputs for the design as well as its interaction with other blocks B2 and B4.
So what was supposed to be just the constraints at the top level now gets trans- lated into many more constraints defined at each interface. And as the number of constraints grows, there are higher chances of errors. In the figure, the partitions are shown as regular rectangular blocks. In reality, all the blocks interact with many blocks, and that increases the complexity of the total set of constraints. Let us consider the interaction between blocks B1 and B2.
Based on this interac- tion, there would be some constraints for blocks B1 and corresponding constraints for block B2. Many times, the people or the team working on these different blocks are different.
There have been many instances where the constraints written for interfacing blocks are not consistent. So between the two blocks, they might consume the entire path time, leaving nothing for the top-level routing for connecting the two blocks. However, such inconsistencies usually creep in gradually as various blocks keep getting impacted due to some other block not meeting their initial requirements. Let us assume block B1 failed to meet some of its timing, which causes an impact on B2.
However, at this stage, either B3 or B5 constraints might get out of sync with the updated constraints of B2, and in many cases, these changed constraints might disturb delicate balance of area, perfor- mance, and power. Thus, the block-level constraints may have to be updated depend- ing on how the block is integrated in the subsystem or chip. There could be different peripherals for these cores. These may be eventually caught during full-chip STA, post integration. That could be pretty late as the block constraints would now have to be redone to the original specification adding an unnecessary iteration to the chip integration.
Synthesis has been used just as an example of an implementation tool. All implementation tools are driven by constraints. Most of the discussions mentioned in this chapter would apply to all implementation tools, not just synthesis. So incorrect constraints impact the ability of these tools to implement a circuit which will meet its performance, area, and power goals. As design complexities are growing, the constraints themselves are also becoming complex — in order to be able to correctly represent the complex requirements as well as relationships.
The nuances of the design process involving partitioning, integra- tion, and multiple cores operating at different frequencies all add to further problems around creating constraints.
Several implementation tools also allow constraints to provide physical informa- tion, such as physical shape of a block, or specific location of ports, etc. These physical constraints are not covered in this book. Chapter 3 Timing Analysis and Constraints Before we learn to constrain our design, let us first understand the basics of timing analysis.
Fundamentally, timing analysis is of two kinds: By knowing the time difference between the inputs applied and the signals observed, we know how long the signal takes to travel through the specific path segment. For flops, by observing when D input arrives with respect to the CLK input, we know whether or not the specific flop meets the setup and the hold requirements. Thus, this process is dependent on timing simulation and is dependent on the stimulus being applied. On the other hand, static timing analysis analyzes the circuit topology to compute the same information without the need for any input vectors.
Usually, timing analysis means static timing analysis. In the context of this chapter also, timing analysis would mean static timing analysis, unless otherwise mentioned. Since then, static timing analysis STA has been gaining ground as the preferred method for timing analysis.
STA is not dependent on the input vectors. STA involves analyzing the circuit topology and computing the time window within which various signals can reach various points in the circuit and then comparing it against the time when those signals are required at that point. As long as the range of time during which the signals arrive meets the required time, the design is clean — from STA perspective. Starting with Chap.
For the time being, let us consider a very abstract view of a circuit — as shown in Fig. STA would know at what times the signals can arrive at inputs I1 and I2 and all other inputs. Now, STA would compute at what time these signals can reach the output O1 and all other outputs. STA would also know at what time the signal is required at the output O1. By comparing the time that the signal is available at O1 — with the time when it is required — an STA tool will report whether the timing has been met or failed.
If the circuit contains some flops, then, STA will also need to compute at what time each flop receives its clock and data. STA tool will then com- pare the data and clock arrival time on each flop with the setup and hold requirement for the flop. If the data arrival time does not meet the setup and the hold requirement for the flop, STA tool will report a violation. Let us dive slightly deeper into the circuit shown by Fig.
Let us say, Fig. For this portion of the circuit, the data at F1 should arrive before the setup window starts for F1, for each active edge of clock on F1. On the other hand, the data should arrive only after the previous data has been captured reliably i. This depends on the time at which triggering edge arrives on F1, the delay through the combinational circuit C1, and the input arrival time at I1. Because STA depends so heavily on delay calculation, it can only be carried out after the gate-level netlist is available.
Even for gate level, as the design progresses further into the flow, the estimates for routing delays and capacitive load become more accurate, which allows for better delay computation and so more accurate STA. It also takes in library inputs — mostly to know about technology-dependent characteristics, e.
Another set of inputs that STA tools need are related to the arrival time and other characteristics of various signals at the inputs and the time at which various outputs are required. These inputs are provided through timing constraints. Timing con- straints perform several roles during an STA. The tool need not validate these statements for accuracy or correctness. The tool should simply use this as an input for itself, in order to validate that the timing would be met.
Typically, this is information about some condition external to the design — something that the tool cannot determine on its own. For the circuit given in Fig. The tool needs to validate that the design meets these constraints. This is what the STA is about. After doing various computations, if the tool finds that the timing meets these constraints, STA is considered as pass, or timing is considered to be met.
Alternately, if these constraints are not met, STA or timing is considered as failed. Looking at the same example circuit as shown in Fig.
This happens for implementation tools, such as synthesis or place and route. These implementation tools take these constraints as a goal that they try to meet. Let us consider the circuit shown in Fig. For the example circuit, a clock tree synthesis tool will now put an elaborate network structure so that each of the 1,s of flops can be driven by this network.
An example directive for such a clock tree synthesis tool could be the delay for the clock network. The clock tree synthesis tool should implement the tree network in such a manner that the delay through the network meets the specified value.
Suppose certain paths are constrained to meet certain timing.
However, for some special reason, there is no need for those paths to meet those timings. Or, they can work well, even if they are given much more relaxed requirements. These are called timing exceptions. Chapters 11 and 12 have several examples of such timing exceptions. It could be a statement at one stage of the design, and at another stage of the design, it could become a directive.
There is a constraint which specifies the delay through the clock network. If somebody wants to do an STA before the clock network has been synthesized, then, this constraint i.
The STA tool should simply assume that the delay through the clock network is the specified value. Now, during clock tree synthesis, this same constraint becomes a directive.
The clock tree synthesis tool needs to synthesize the clock network such that the delay through the clock network is equal to the value specified. Once the clock tree synthesis has been done, the STA can compute the actual delay through the clock tree network. The same constraint becomes meaningless and should be thrown away!!! Thus, the same constraint delay through the clock network: For the given circuit, there will be a constraint specifying the output required time.
C1 should be realized in such a manner that the delay through it still allows the signals to reach output O1 at the required time. On the other hand, for an STA tool, this constraint acts as an assertion. The STA tool needs to check that the output is available at O1 at the required time.
If the output is not available at the required time, it should report an STA or timing failure. Thus, timing constraints could be an input statement or an assertion or a directive or even a relaxation called timing exception. In most cases, the constraint itself does not indicate what role the constraint is playing. The role of the constraint has to be determined depending upon the context. There are many chips which were STA clean but did not operate correctly.
A clean STA causes the designers to get too confident. It does not cover or verify anything else. It does no checking at all about functionality. A clean STA has no guarantee that the circuit will give the desired functionality. A clean STA would only mean that the circuit will operate at the specified frequency. Simulation, assertion-based checks, FPGA prototyping, etc.
The STA tools do not question these statements of designer intent. The STA tools simply assume these constraints to be true. In most cases, they might not even have the information required to verify these constraints. If a user makes an error in giving such constraints, the tool could give erroneous results. And, a design which does not meet desired timing might simply appear to be STA clean — due to user error in giving incorrect constraints.
Even if there are portions of circuits where timing characteristics could be deter- mined, user-provided constraints generally override what can be implicitly inferred. For example, for generated clocks e.
However, the user-specified characteristics override, even if they are incorrect. Details on such scenarios are explained in Chap. Figure 3. The horizontal axis denotes the constraints required for the desired frequency of operation. The vertical axis denotes the constraints actually applied on the design. Moving away from the origin signifies tighter constraints.
The constraints actually defined should be the same as what is actually required. A point below the line means that the constraint applied is more lenient com- pared to what is required. This means the STA might appear to be clean, but it has been done against conditions more lenient than the actual requirements, and so the final device might not really work at the desired frequency. An obvious solution is that the constraints should always be applied either on the line or above the line.
This will ensure that the constraints are tighter than what is really needed. A clean STA here would ensure that the design is really timing clean. However, applying tighter constraints has its own set of problems. These higher drive cells mean higher area and power. Thus, the paths which really need better resources might get lesser priority, because another path had been given an unnecessarily tighter constraint.
The design might not meet timing, because it has been specified a much tougher constraint than what is really needed. This might cause a lot of time to be spent unnecessarily — in trying to meet timing that is not even needed. Thus, ideally the constraints should be applied just on the line — neither tighter nor lenient than the requirement.
In case of a doubt, one has to err on the side of being a bit tighter. Timing exceptions are the most misunderstood form of constraints. By specifying these exceptions, sometimes users provide leniency to paths, where it should not be provided.
The errors could be in clock period or waveform. However, the more common problem is around generated clocks. However, the resulting generated clock waveform might have its positive and negative edges swapped — if not specified carefully. Many a time as a design keeps getting retargeted or reused, the RTL gets updated.
However, the corresponding constraints are not updated. But, more often than not, it happens because a user does not easily see the correlation of the RTL changes with the changes that are required in the constraints.
In subsequent chapters, we will see the implications of various switches and options on many of the commonly used constraints. Each of these as a corollary also indicates the kind of mistakes that users might make while writing the constraints. A good set of constraints should satisfy the following conditions: Section 3. This helps in review and catching mistakes, and it also insulates the constraints from minor changes in the design.
For example, for the circuit in Fig. Another user might declare a false path between Clock1 and Clock2. Though, from the STA perspective, all three have the same impact, but from understanding the intent perspective, the third one asynchronous clock groups is the best in conveying exactly the reason for the constraint actually, an excep- tion , while the first one false path between the two registers is the worst; it does not highlight that the false path is due to the clocks being asynchronous and has really nothing to do with the actual path between the two registers.
Looking at Fig. However, if the RTL is modified so that either of the clocks gets used before muxing also, then the above exception gets invalidated and is most likely to get missed being updated.
For example, instead of the input transition being specified in terms of a specific transition value, it is better to specify the driver cell. As technol- ogy changes, the new drive strength of the driver cell would be considered. It helps readability and reuse and most tools have lesser memory footprint for concisely written constraints.
Most SDC-based tools allow support for wild- cards. However, an extensive usage of wildcard is not considered efficient, even though the constraints become concise.
This is because wildcards could match additional objects also. Constraints written to satisfy the above characteristics are less error prone. STA depends heav- ily on delay calculation. Delay calculation has applications other than STA also. Delay calculation for a given process, temperature, and voltage conditions per- forms the following activities: After this, the delay values might be used directly by an STA tool for its analysis.
In this case, the delay calculator is a part of the STA tool itself. Or, the various delay values might be written out in an SDF standard delay format file. In this case, the delay calculation and STA are per- formed by two different tools. Collects all statement-type constraints, e. Passes some statement-type constraints to delay calculators, e. Looks at the circuit topology to identify various timing paths 4.
Obtains the path delays from the delay calculator 5. Combines 1 and 4 to compute the arrival time of the signals at the desired points 6. Compares the signal arrival time with assertion-type constraints which tell when should the signal be available there 7. Provides a result — based on actual arrival time and the required time Clearly, the correctness of the STA depends very heavily upon the underlying delay calculation.
Along a timing path, the signal only encounters the delay through the circuit elements. Thus, for a given circuit, all inputs act as start points. The point at which a signal has to be timed is called an end point.
Thus, all outputs act as end points. So the transitions which reach till D now have to wait. The timing for the signal propagat- ing further will now depend on when the clock arrives. This is the place where the D should be checked for meeting setup and hold requirements. Thus, the timing path ends here.
So registers also act as end points. Similarly, registers also act as start points. A signal will start from the Q pin of the register and then propagate forward. Strictly speaking, the timing starts from the clock source, reaches the clock pin of the flop, and then goes to the Q pin of the flop and then proceeds further.
So, in a strict sense, the register is not really a start point. However, for most practical purposes, registers are referred as start points. Though during actual analysis, the path tracing starts from the clock source, for the circuit shown in Fig. Start points are: End points are: A signal reaching the asynchronous clear pin of the flop need not wait here for any other trigger. It can simply continue through the Q pin of the flop and onwards.
Thus, timing path need not end here. So while D pin of a flop acts as an end point, an asynchronous clear or set pin might not be an end point. By specifying a starting point or a checking point, the path gets broken at that point. For example, in the same Fig. In such a case, a check has to be made at N2. Thus, N2 becomes an additional end point. And it also becomes a start point for the next segment of the path, namely, N2 to O3.
Similarly, since the signal tracing is starting from N1, it becomes a start point. And it also becomes an end point for the previous segment of the path, namely, I2 to N1. Now, if a user had specified a delay for I2 to N1, then, N1 would become an end point.
It would also become a start point for the next path segment. However, I2 remains only a start point. It does not become an end point, because there is no previous path segment.
However, if a recovery — removal check is applied on the clear pin of F3, then the path gets broken at that point.
It is different from a functional path. A functional path means the topology along which a signal travels. After that, when the conditions are right viz. So this is a functional path. However, this is not a timing path. Because, irrespective of when the signal arrives at D, we do not know when will it proceed ahead to cross the flop. It would depend on when the clock trigger arrives at the flop. Timing path means, when a signal arrives, we can say when the next transition in the path will happen.
For example, when the clock trigger arrives, we know the next transition will happen at the flop output. The actual transition may or may not happen. For example, if the D has the same value, the Q would remain unchanged.
The timing path indicates the possibility of a transition. Thus, timing paths indicate the sequence along which transition would follow without having to wait for any other event to happen. The actual value could be coming from somewhere else.
Functional paths indicate the sequence in which val- ues would change. The timing of the value change might still be controlled by something else. Sometimes, a timing path and a functional path could overlap, e. So data path could be: In general terminology, setup means the time before a clock edge before which the data should be stable on the D or any other synchronous pin of a flop. Hold means the time after a clock edge for which the data should be held stable.
Thus, setup check can be made at any end point — not just the flop. A setup check would be made even at outputs. Setup can be defined in a more generic way as follows: The data needs to be set up and available before some reference event. In the case of a flop, the reference event is the clock trigger. O FH F1 Fig. Assume that the clock has a period of This require- ment can be thought of as a setup requirement of 4 10 — 6 on a hypothetical flop FH — shown in dotted lines , which sits beyond the output port O.
So this setup check can be made at the output. Thus, like setup, hold check can be made at any end point, including at outputs — not just the flop. Hold can be defined in a more generic way as follows: The data needs to be held and left undisturbed after some reference event.
For the output O, let us assume that the output is required to be held for 2 time units after the clock edge. This requirement can be thought of as a hold requirement of 2 on the hypothetical flop FH , which sits beyond the output port O. So a hold check can be made at the output. Thus, for the data path, it computes the maximum delay.
Thus, it is also called max analysis. Since setup check considers the latest arriving data, it is also called late analysis. Similarly, hold check ensures that even the fastest moving data should not disturb the data, while it is expected to remain stable. Hence, for the data path, it computes the minimum delay. Thus, it is also called min analysis. Since hold check considers the earliest arriving data, it is also called early analysis. Setup — hold analysis of STA is also called min — max analysis or early — late analy- sis.
It is more important to be familiar with the concepts, rather than getting too worried about the terminology. Sometimes, different tools might use different ter- minology for the same concept. Or, sometimes, even the same terminology is used to refer to different concepts in different contexts. Besides setup or hold analysis, STA performs pulse-width, recovery, removal analysis, etc.
Say, a signal is required to be available before time 6 setup analysis. The last signal arrives there at time 4. So the signal has a margin to take an additional 2 time units, without risking the operation of the design. This 2 is called setup slack. Similarly, say a signal is required to be kept stable till time 2 hold analysis. The earliest a new signal reaches there is at time 5. So the signal has a scope for getting faster by another 3 time units.
This 3 is called hold slack. Let E1 be the edge, where data needs to be captured. S represents a time which is ahead of E1 by a duration equal to setup requirement. So the latest data should reach the end point before time S. Let us say that the last arriving change happens at time Ma.
So the setup slack is the duration Ma — S measured by S — Ma. Just like the data has to arrive before S, similarly, the data should not arrive so early that it can interfere with the capture of the data at the previous edge. Let E0 be the previous edge, where previous data is supposed to be captured.
For a reliable capture of the previous data, the current data should not disturb it till the hold requirement from E0.
Let H represent a time, which is hold time after E0. So the current data can come only after H.
Let us say that the earliest arriving change hap- pens at time Mi. So the hold slack is the duration H — Mi measured by Mi — H A positive slack means timing has been met. And, a negative slack means the timing has not been met.
However, for any of the tools, they would trace the delay maximum for setup analysis and minimum for hold analysis through the path and also trace the time required for the signal. It would then compare the two numbers and provide the slack number either positive or negative. The path delay or the required time computation also considers the delay along the path of the clock that is used to trigger the launch of the data at the start point and the capture of the data at the end point.
We want to do a setup analysis at flop F2. So the slowest data path has to be considered. So we will consider the maximum delay for: Thus, we have to consider the clock path till flop F1 also with maximum delay. This same clock is also reaching flop F2 and acts as the reference event for the setup check. If we treat the clock path with maximum delay, then the reference event also gets delayed, which might allow additional slack for the data to arrive. So, for the clock path for the flop F2, the minimum delay is considered.
This differential treatment for the different segments of the same network accounts for any variation on different portions of the same chip and is called on- chip variation. This on-chip variation reduces the slack. There is a segment of the clock network which is common to both the launch and the capture flops from the Clk port till A. The clock traversal through this segment will have the same delay whether for cap- ture flop or the launch flop.
This segment which is common to both the flops is considered to have same delay values. This prevents over-pessimism. Some tools apply on-chip variation for the whole clock path, including the common segment.
After that, they apply a correction factor to compensate for the differential delay considered in the common segment. This gets reflected in a term called clock net- work pessimism reduction or clock tree pessimism reduction. STA is used to do setup and hold analysis and compute the slack for the paths being analyzed. In order to do this analysis, STA depends very heavily on delay calculations. This chap- ter provides a brief history of timing constraints and an overview of the SDC format.
These were mainly used for specifying design characteristics that could not be captured in the HDL and were used to drive synthesis. Over the years this set was extended to capture design requirements for power as well. SDC commands are based on the Tcl language.
By making SDC an extension to Tcl, tool-specific commands can be intermixed with native Tcl con- structs like variable, expressions, statements, and subroutines, making it a very powerful language for implementation tools. Today most implementation and STA tools use SDC as the standard format for capturing design intent for area, power, and performance.
However, specific implementation tools may also use additional commands outside this set in order to guide their specific algorithms or capabili- ties. These commands are generally referred to as the non-SDC commands.
Some of these extensions facilitate the analysis of constraints, e. While some non-SDC commands are still used to capture design intent, they are periodically included in SDC revisions based on its usefulness and popularity. Today Synopsys provides SDC as an open source format for describing timing intent. However, changes to the format are still controlled by Synopsys. SDC documentation and parsers can be downloaded for free from http: This shell along with its SDC extension facilitates users to create Tcl-based wrappers in order to drive vari- ous queries and instructions to the tool.
So it is good to have a reasonable under- standing of Tcl. A basic explanation of Tcl is given here. For a detailed understanding of Tcl, the reader is advised to read a book on Tcl. Tcl is a commonly used scripting language that was developed in by John K.
Ousterhout from University of California, Berkeley. Unlike a compiled lan- guage, where the language is parsed and compiled into machine code before exe- cution, Tcl is an interpretive language where each statement is parsed sequentially and executed right away. Hence, the language stops at the first error it encounters in a script.
Tcl follows some basic semantics in its scripting. Each Tcl statement ends with a newline character or semicolon. If a statement spans multiple lines, then to con- tinue on the next line, a backslash is provided at the end of the line. Every statement and its arguments are treated as strings. A string with more than one word enclosed in double quotes or braces is considered a single unit.
A statement beginning with is considered a Tcl comment. Here are a few examples: Words separated by white space are treated as multiple arguments to the statement.
This will give an error indicating it cannot process the arguments. Error will show up as: Pages Synthesis Basics. Timing Analysis and Constraints. Generated Clocks. Clock Groups. Other Clock Characteristics. Port Delays. Completing Port Constraints.
False Paths. Multi Cycle Paths.
Combinational Paths. Modal Analysis. Managing Your Constraints. Miscellaneous SDC Commands. Xilinx Extensions to SDC.