Constraints are essential when developing a new design. The constraints set up are the environmental, clock, test and power boundaries the designers must keep themselves within when designing an ASIC. The constraints set up is often captured and written in a Synopsys Design Constraints file (SDC). In order to implement the functionality when a new ASIC is under development, the designers review the design specification.

In order to develop a design that will make sense in reality, it is at least as important to have a complete constraints set up and to verify the design against it during the development phase. If there are new ports added in the design, parameters constraining these port must be added in the constraint set up. If adding a constraint is omitted, the result could be fatal and thus cost vast amounts of money. Therefore Spyglass functionality regarding verifying the constraint set up coverage, correctness and consistency were evaluated. It was also desired to check Spyglass functionality regarding verification of Multicycle Paths (MCP).

 Spyglass ability in terms of checking constraints cover and whether the constraints are followed in the design were evaluated. The evaluation was done on the RTL code of the block. The reason for this choice was that the block in question had a large number of associated constraints in the SDC file.

The constraints belonging to the block was extracted from the original ref.sdc and interpreted to map RTL instead of netlist. When running Spyglass the two default templates  ie the Constraints/sanity check and Constraints/synthesis were used to evaluate the constraints set up. Constraints/sanity check was used mainly to check whether signals defined in the SDC file had equivalences in the code. The Constraints/synthesis contains rules for RTL pre synthesis runs and this was the one that was used for the actual SDC evaluation.

 Size and complexity of new architectures are growing fast which in turn makes the testing procedures harder. It is therefore important for the designers to follow the Design For Test (DFT) technique. DFT can be described in short as making the validation process easier and simpler by taking testing in consideration from the beginning of the design process. To achieve a design that is easy to test, the two terms controllability and observability are used. Controllability – measures how easy it is to bring a node into a sought state, only stimulating input pins.Observability – measures how easy it is to read the value on a certain node at the output pins. One of the approaches under the DFT technique is Scan-Based testing. This means that flip flops are directly connected with each other in a long chain, from chip input to output. The testing personnel are then able to scan desired values into the design using predefined test vectors. The vectors put the design into desired states which are excited whereupon the new states are scanned out and read at the outputs. The work of implementing an effective scan chain puts great demands on the design regarding the observability and controllability properties previously mentioned. Spyglass capability of checking these properties early in the design phase was interesting and therefore evaluated.

The three properties Spyglass checks for are given below.

 ·        All registers should be controlled by a test clock.

 ·        All resets and sets should be disabled in test mode.

 ·        All registers should be scannable.

 As new hardware designs are getting larger, clock path length becomes critical. In order to shorten the clock path, and thus avoid clock skews that are too large to be handled, a common design method used is Globally Asynchronous Locally Synchronous (GALS).The blocks are then connected with each other through an asynchronous handshaking mechanism or a FIFO .

On each of the communication paths between the individual synchronous blocks there will be one or more Clock Domain Crossings (CDC). In the basic CDC package there are rules for checking the meta stability problem mentioned above, reset is correctly de-asserted, the presence of a CDC, rules to check for a custom CDC structure etc.

In the advanced CDC package there are rules checking over/underflow of FIFO, if data is stable during the entire period of the require signal, reconverging synchronized signals, the correct implementation of busses crossing domains, the existence and structures of a fast to slow clock domain etc. Even thought not many CDC exist in the present designs, it was decided that some of Spyglass CDC checking functionality were to be tested due to the severity of a CDC error. Auto-Verify policy in Spyglass contained functionality to verify false paths and later on multi cycle paths.

Another interesting aspect was the SOC rules in the DFT policy. These rules were supposed to be able to verify that signals specified in the SGDC file were correct with different input stimuli.Spyglass only investigates the source code and no synthesis is needed. This is also the case for checking if a flip flop has a reset. If a rule that checks whether this reset is the one specified in the Spyglass Design Constraints file,then Spyglass must synthesize the design. The rules that are run depend on the templates that are selected. A template in Spyglass is a set of rules. When structural and functional rules are run Spyglass must be supplied with an SGDC file. This file contains information regarding clocks, resets, test mode signals, additional Synopsys Design Constraints files etc.

An example is the specification of the master clock. In order to check clock tree propagation Spyglass needs information regarding where to start the checking.In order to check clock tree propagation Spyglass needs information regarding where to start the checking. Below is a typical clock.

clock –name I_REF_CLK –domain domain1 –value rtz -sysclock

 The set of rules runs fast even on large designs that have not been checked before. In the message view – spyglass tab, the rule “DetectBlackBoxes” reports violations if there were any black boxes. This rule was used to identify libraries that have not yet been provided. Even though Spyglass was able to run without these missing libraries/code the checking performance increased if they were included. Functionality and rules that depended on clock, reset and test mode propagation would not be optimal if there were black boxes in their paths. Spyglass could use both .db and .lib library files but the .lib files were preferred. When the rule InferredBlackBoxes was violated and flagged a black box it provided both the instance name as well as the expected module/cell name.

 The template provided from the ASIC vendor was selected to be used in this part of the evaluation. This template contains all the rules in the stdc-policy. These are naming conventions, RTL coding rules and design rules.The ASIC vendor’s add-on consists of the following two policies such as set one, various rules for poorly implemented design, set two, rules to check constraints coverage and correctness.

During the environment set up procedure, Spyglass can be a valuable asset in terms of identifying black boxes. The template Audit/Audit-RTL provides rules that check the design for correct linking, syntax errors and black boxes.

  Starting Spyglass is done with the spyglass command. There are a number of switches to be used depending on the type of evaluation the user desires. Table shows the switches and commands that were used during this evaluation.When running checks, Spyglass generates a couple of reports. What reports that are generated vary depending on what rules that were selected for that particular run.

In order to make the violation comparison, the default report named “Count” was viewed and considered. This report lists all the rules that generated errors, warnings and information during the run. For each listed rule the report also presents the number of violations it had. The two reports from the consecutive runs were copied together into an excel spreadsheet and compared.

If the number of violations a rule had generated differed, it was taken into account for further examination. Exceptions to this procedure were made to rules considered to be extra important. They were examined even if they had generated the same number of violations. If this was the case the violations were traced further trough the netlist versions.

 Important rules in RTL-Signoff

Before the RTL-Signoff template was applied on any of the blocks, the selected rules were surveyed to determine if there was anyone considered to be of extra importance. The reason for this was to render the evaluation to be more efficient. Experiences gained after a test run with default Spyglass rules, were that there would be a lot of violations from a large number of rules.

 Deeper knowledge and understanding about the checking functionality of certain rules were therefore of great asset. The chosen rules were considered even if there were no deviation between two netlist versions. The character of these rules were such that if they occurred, the source to the violations had to be traced further. Below is a list of the names of these selected rules along with an explanation to why they were given extra attention.

 ll flip-flops must be initialized from external resets.This is a very important rule. The value of a reset that is not externally controlled would be almost impossible to predict or controlled. This is especially true for flip flops that lack a reset signal all together.

 Avoid constant values on the data input pin on flip flops. There is no point in setting a data pin of a D-flip flop to a constant value.The only thing this will result in is extra silicon and power consumption. The possibility of an unintended construct is high.

 Do not use combinational feedback loops. Combinational loops are bad design practice and synthesis tools will eventually break them in an uncontrolled way. The problem is that this might alter the designer’s intention and cause the design to misbehave.

It is better if they are broken in a controlled way (by inserting a flip flop manually), or to remove them entirely if they are unintended. This is probably not a problem on gate level since a synthesis tool would have had removed the loops. But if the netlist is patched manually after an error it could potentially occur.

 Preferably use clock signals active on the rising edge only. The most common practice is to have the entire design to trigger on active edge of the clock signal. This makes both the verification task easier as well as meeting the timing constraints. High risk of unintended construct. There are design exceptions, such as a Double Data Rate (DDR) mechanism.

 Do not use D flip flops nor latches with connected set and reset pins. A D-flip flop has either reset or set, not both like an Set/Reset (SR) flip flop. If they are both set and reset, different tools in the flow might have different priority levels on the signals and hence make the design work in an unintended way.

 A net driving several outputs is not allowed. Having a net driving several outputs is often unnecessary and can result in redundant area and silicon. There are cases though when this behaviour could be desirable. Preferably register all top level outputs. It should be a practice to register all top level outputs although there are exceptions when this could be overseen.