CDC

 

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.

 

spyglass –verilog –policy=stdc –template stdc/RTL-Signoff

–f <PATH>sglib_list <PATH>design.v –sgdc constraints.sgdc

 

Table:Commands and switches used

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.