1. What are the constraints that will be used during STA?

The constraints used in Static Timing Analysis (STA) are primarily defined using Synopsys
Design Constraints (SDC), which is the industry-standard language. These constraints are
essential for the STA tool to calculate timing slack and verify that the design meets its
performance requirements. The main categories of constraints are:

Constraint
Purpose Key SDC Commands
Type

Define all primary and generated clocks in

Clock create_clock, create_generated_clock,
the design, including period, waveform,
Constraints set_clock_latency, set_clock_uncertainty
latency, and uncertainty.

Define the external timing parameters for

I/O Port set_input_delay, set_output_delay,
input and output ports, such as external delay
Constraints set_driving_cell, set_load
and driving cell characteristics.

Override or modify the default timing set_false_path, set_multicycle_path,

Timing
analysis rules for specific paths that do not set_max_delay, set_min_delay,
Exceptions
require standard setup/hold checks. set_clock_groups

Define the environmental conditions

Operating set_operating_conditions,
(temperature, voltage, process corner) under
Conditions set_wire_load_model
which the analysis is performed.

STA uses these constraints to check if all timing paths (data paths between sequential elements
or between I/O ports and sequential elements) meet the required setup and hold times [1].

2. Whether we use any tools to automatically write constraints or

manually write it.
The process of writing constraints is typically a hybrid approach combining manual effort
and tool automation:

1 Manual Writing: The fundamental and most critical constraints (e.g., create_clock for
primary clocks, basic I/O delays) are usually written manually by the design or STA
engineer based on the design specification.
2 Tool Automation: Electronic Design Automation (EDA) tools provide significant
assistance:
◦ Generated Clocks: Tools can often automatically derive generated clocks
from clock-modifying blocks like PLLs or MMCMs, or the engineer can use
the derive_pll_clocks command.
◦ Timing Exceptions: Specialized tools like Synopsys Timing Constraints
Manager (TCM), Cadence Conformal Constraint Designer, or Excellicon
ConMan can analyze the Register-Transfer Level (RTL) code to automatically
infer and generate complex exceptions like false paths (set_false_path) and
multi-cycle paths (set_multicycle_path). This automation reduces manual errors
and accelerates the design cycle [2, 3].

Conclusion: Effective constraint management relies on manually defining the core constraints
and using specialized tools to automatically infer and manage the complex timing exceptions.
3. Whether we use any tools to check/validate constraints.
Yes, constraint validation is a mandatory step in the design flow. Specialized tools and features
are used to ensure that the constraints are:

• Syntactically Valid: Free from SDC syntax errors.

• Physically Valid: Constraints reference actual, existing ports, pins, or nets in the design
netlist.
• Logically Valid: Constraints are not contradictory (e.g., two clocks are not declared as
both synchronous and asynchronous).
• Complete: All clocks and I/O ports are properly constrained.

Key validation tools include:

• STA Tools (e.g., PrimeTime, Tempus): These tools inherently report basic syntax and
reference errors.
• Dedicated Constraint Validation Tools: Tools like Cadence Conformal Constraint
Designer perform formal analysis on the SDC and RTL to find issues such as
redundant constraints, missing constraints, or conflicting exceptions [3]. This ensures
the constraints accurately reflect the design's intent before synthesis and
implementation.

4. The constraints have to be given to synthesis tools, whether we

are aware of the synthesis tools and their flow.
Yes, SDC constraints are a critical input for synthesis tools.

Common Synthesis Tools:

• Synopsys Design Compiler (DC)
• Cadence Genus
• Mentor Graphics (Siemens EDA) RTL Designer

Basic Synthesis Flow:

3 Inputs: RTL code (Verilog/VHDL), Technology Library (containing standard cells),
and SDC Constraints (defining timing goals).
4 Translation & Optimization: The tool translates the RTL into a gate-level netlist
using cells from the technology library. It then optimizes the netlist (e.g., selects gate
sizes, inserts buffers) to meet the timing goals specified in the SDC file.
5 Output: An optimized gate-level netlist and timing reports confirming that the SDC
constraints have been met (or reporting violations).

The SDC constraints effectively guide the synthesis tool's optimization decisions, ensuring the
resulting netlist is capable of meeting the required performance targets throughout the rest of
the physical design flow (Place & Route).

5. Arguments used in generated clock constraints.

The primary SDC command for defining a generated clock is create_generated_clock. The
most important arguments include:
 Argument Purpose Required/Optional

<name> The name of the generated clock. Required

Specifies the pin or port from which the clock is derived. This
-source
is the point where the master clock enters the clock-modifying Required
<source_pin>
logic (e.g., PLL input pin).

-divide_by Specifies the frequency division factor relative to the source

Optional
<factor> clock.

-multiply_by Specifies the frequency multiplication factor (commonly used

Optional
<factor> for PLL outputs).

-duty_cycle
Specifies the duty cycle of the generated clock. Optional
<percent>

Specifies which edges of the source clock are used to create

-edges <edge_list> Optional
the new clock. Used for complex clock dividers/multipliers.

-master_clock Specifies the master clock if it is different from the clock on

Optional
<clock_name> the -source pin.

Example:

# Master clock 10ns period

create_clock -name CLK_IN -period 10 [get_ports CLK_IN]

# Generated clock from PLL, multiplied by 2 (5ns period)

create_generated_clock -name CLK_PLL_OUT \
-source [get_pins U_PLL/CLK_IN_PIN] \
-multiply_by 2 \

[get_pins U_PLL/CLK_OUT_PIN]

6. What does asynchronous clock group mean?

An asynchronous clock group is a set of clocks that have no fixed, predictable phase or
frequency relationship with each other.

When two clocks are declared as asynchronous using the set_clock_groups -asynchronous
command, the STA tool will ignore all timing checks (setup/hold) for data paths that transfer
data between the two clock domains.

SDC Command:

set_clock_groups -asynchronous \

-group {CLK_A CLK_B} \

-group {CLK_C}
In this example, paths between CLK_A/CLK_B and CLK_C are ignored.

Rationale:
• Asynchronous clocks often originate from independent oscillators or external sources.
• Traditional STA is meaningless for these paths because the phase relationship is
constantly changing or unknown.
• Data transfer between asynchronous clock domains must be handled by dedicated
Clock Domain Crossing (CDC) circuitry, such as Asynchronous FIFOs or two-flip-
flop synchronizers. Specialized CDC tools are then used to verify the safety of this
handshake logic [4].

7. Whether ref clock input to pll and its output clock are
synchronous.
Yes, they are synchronous.

a. How can we say it is synchronous?

The output clock of a Phase-Locked Loop (PLL) is generated by locking its phase and
frequency to the reference clock input. While there is a fixed phase offset (latency) between
the input and output, the frequency and phase relationship between them is fixed and
deterministic, defined by the PLL's multiplication and division factors.

• Synchronous: A fixed, predictable timing relationship exists.

• Asynchronous: A random or non-fixed timing relationship exists.

Since the PLL maintains this fixed relationship, the output clock is considered a generated
clock of the reference clock, and the path between them is treated as synchronous by STA.

b. If the ref clock and pll output clock goes to different FFs, whether we can
call they are synchronous?
Yes, they are still considered synchronous.

The fact that the two clocks drive different Flip-Flops (FFs) simply defines an inter-clock
path. As long as the timing relationship between the two clocks is fixed (as is the case with a
PLL), the path is considered synchronous and must be checked for setup and hold violations
by the STA tool.

• STA Check: The tool will check the data path from an FF clocked by CLK_REF to an
FF clocked by CLK_PLL_OUT (and vice versa).
• SDC Constraint: The create_generated_clock command is used to define
CLK_PLL_OUT relative to CLK_REF, allowing STA to accurately calculate the
required timing budget.
8. What does logically exclusive and physically exclusive clock
group means?
Both are types of timing exceptions used to tell the STA tool to ignore paths between certain
clocks, but they represent different physical realities in the design.

Physically Exclusive (- Logically Exclusive (-

Feature
physically_exclusive) logically_exclusive)

The clocks can be physically active

The clocks cannot be active simultaneously
simultaneously, but the design logic
Meaning on the chip. Only one clock can be running at
ensures no functional data transfer
any given time.
occurs between them.

Typically implemented with a clock

Implemented by design logic where two
multiplexer (clock MUX) where the select
Implementation separate functional blocks, each with its
signal ensures only one primary clock is
own clock, never communicate data.
propagated to the rest of the design.

To prevent STA from checking paths that are To prevent STA from checking paths
Purpose physically impossible (since only one clock is that are functionally irrelevant (since no
active). data transfer is intended).

set_clock_groups -physically_exclusive - set_clock_groups -logically_exclusive -

SDC Command
group {CLK_A} -group {CLK_B} group {CLK_A} -group {CLK_B}

9. Where can we apply logically exclusive clock group constraint.

The set_clock_groups -logically_exclusive constraint is applied in scenarios where two or more
clocks are present and running, but the design's functional specification dictates that data
transfer between the domains is not intended or is handled by non-timing-critical means (like
configuration registers).

Typical applications include:

6 Mode Clocks: When a design has multiple operating modes (e.g., Test Mode, Normal
Mode, Sleep Mode), and each mode uses a different clock. All clocks may be physically
running, but the control logic ensures that only the FFs clocked by the currently active
mode's clock are functionally relevant.
7 Independent Functional Blocks: Two large, separate functional blocks (e.g., a PCIe
controller and a DDR controller) that operate on different clocks and are designed to be
completely isolated in terms of data flow.
8 Shared Clock Tree Logic: In cases where the clocks share some common clock tree
logic, logically_exclusive is preferred over set_false_path because it still allows the
STA tool to check for clock-to-clock crosstalk or other physical interactions within the
shared clock network, while ignoring the data path checks.
10. If the designer doesn't specify the input clock frequency, how
can we write constraints for that?
If the designer fails to specify the input clock frequency, this represents a critical deficiency
in the design specification. The clock frequency is the most fundamental parameter determining
the chip's performance target.

Here is the recommended approach:

9 Mandatory Clarification (The Best Approach): Immediately request the designer

or project manager to provide the intended operating frequency. Without this, any
subsequent STA or synthesis work is based on an assumption and cannot guarantee the
final product's performance.
10 Use the Target Frequency: If the exact frequency is unavailable but the performance
target is known (e.g., the chip must run at 500 MHz), use that target frequency to define
the clock.
◦ Example: For a 500 MHz target, the period is 2.0 ns.

# Assuming a 500 MHz target frequency (2.0 ns period)

create_clock -name CLK_IN -period 2.0 [get_ports CLK_IN]

11 Use a Conservative Frequency (If Forced): If absolutely forced to proceed without a

specification, a very conservative (slow) frequency can be used for initial synthesis to
avoid over-constraining the design. However, this will not validate the actual
performance.
12 Infer from I/O Delays: In rare cases, if the I/O timing requirements are specified (e.g.,
set_input_delay values), you might be able to infer a minimum required frequency, but
this is highly unreliable.

In summary: The input clock frequency is non-negotiable for meaningful STA. The constraint
must be written based on the expected or required operating frequency.

References
[1] Synopsys. What is Static Timing Analysis (STA)? – How STA works? [Online]. Available:
[Link]

[2] Blue Pearl Solutions. Automatic SDC Generation. [Online]. Available:

[Link]

[3] Cadence. Encounter Conformal Constraint Designer DataSheet. [Online]. Available:

[Link]
[Link]

[4] Intel. Asynchronous Clock Groups. [Online]. Available:

[Link]
[Link]
11. Spyglass cdc flow or different goals set during cdc analysis.
The SpyGlass CDC (Clock Domain Crossing) flow is a structured methodology to ensure
reliable data transfer between different clock domains. The flow typically involves several
stages, each with specific goals:

Stage Primary Goal Analysis Type

1. Setup & Define the design hierarchy, clock definitions (SDC), and reset
Configuration
Configuration definitions.

Identify all clock domains, all CDC paths, and the synchronizer
2. Structural
circuits used (e.g., 2-FF synchronizers, FIFOs, MUX-based Static/Structural
Analysis
synchronizers).

3. Verification Check the integrity and correctness of the synchronizers. Formal/Structural

Generate reports on unsynchronized paths, improperly

4. Reporting Reporting
synchronized paths, and potential metastability issues.

Different Goals in CDC Analysis:

CDC analysis can be run with different goals depending on the design stage and focus:

1 Structural Goal: Focuses on the physical implementation of the synchronizers. It

checks if the synchronizer logic (e.g., two flip-flops) is correctly instantiated and if the
tool can recognize the synchronization scheme.
2 Setup Goal: Focuses on the completeness of the SDC and reset definitions. It checks
if all clocks are defined and if the reset signals are properly constrained.
3 Functional Goal: Focuses on the functional correctness of the data transfer. For
example, it checks if the control signals (like read/write pointers in a FIFO) are
synchronized correctly before being used in the destination domain.
4 SoC/Abstract Flow Goal: Used for top-level integration where IP blocks are replaced
with abstract models to speed up analysis and focus on the top-level CDC interfaces
[1].

12. Different violation we see during cdc check.

CDC checks identify potential issues that could lead to metastability or data corruption.
Common violations include:

5 Unsynchronized Path: A signal crosses a clock domain boundary and is used in the
destination domain without any recognized synchronizer. This is the most critical
violation.
6 Incomplete Synchronizer: The tool recognizes a synchronizer structure (e.g., two FFs)
but finds a path that bypasses one or both FFs, or the FFs are not placed correctly (e.g.,
not marked as asynchronous).
7 Bus Synchronization Issues: A multi-bit bus is synchronized using individual
synchronizers on each bit. This can lead to data incoherency (skew) if the bits arrive
at different times. This requires a specialized synchronization scheme like a MUX-
based synchronizer or a handshake protocol.
 8 Gated Clock/Reset Issues: A clock or reset signal that crosses a domain boundary is
not synchronized correctly, potentially leading to glitches or asynchronous reset
removal issues.
9 Improper Handshake Protocol: The control signals used in a handshake (e.g.,
request/acknowledge) are not synchronized correctly, leading to potential deadlock or
data loss.

13. Spyglass lint check -how to address lint violations? Waive it or

design change? Some examples where to waive and where to make
RTL change.
Linting is the process of statically checking RTL code against a set of coding rules and best
practices to improve quality, portability, and synthesis results.

Addressing a lint violation requires a judgment call:

Action When to Apply Example Violation

When the violation indicates a

Violation: Unintended latch inference
Design Change functional bug, a potential synthesis
(missing else in an if statement). Fix: Add the
(RTL Fix) issue, or a serious deviation from
else clause to prevent the latch.
coding standards that impacts reliability.

When the violation is harmless, Violation: Unused output port on a module.

Waive intentional, or irrelevant to the specific Waive: If the port is reserved for future use or
(Exception) design context, and fixing it would is a standard part of an IP block that is not
complicate the code unnecessarily. currently connected.

Violation: Using a specific coding style (e.g.,

When the violation is due to a tool
Configuration always @*) that the tool flags as non-standard.
setting or a specific design style that the
Change Fix: Update the SpyGlass rule set or
tool is not aware of.
configuration file (SGDC) to accept the style.

General Rule: Fix functional/structural issues; Waive style/harmless warnings. A waiver

must always be documented with a clear justification.

14. Prior experience in tcl scripts for spyglass cdc.

Tcl (Tool Command Language) scripts are fundamental for configuring and running SpyGlass
CDC. Experience typically involves:

10 Project Setup: Writing Tcl scripts to define the design hierarchy, specify RTL files,
and set up the working environment.
11 SDC Integration: Reading the SDC file and ensuring all clocks and resets are correctly
defined and propagated.
12 Goal Setting: Specifying the analysis goals (e.g., structural, functional) and the rule
sets to be executed.
13 Exception Handling: Writing Tcl commands to define CDC exceptions, such as
declaring specific paths as false paths or specifying custom synchronizer types that the
tool should recognize.
14 Report Generation: Customizing the output reports to focus on critical violations and
filtering out known waivers.
15. What is the maximum number of clocks I have used in my
previous project.
This is a personal experience question, but a typical answer should reflect the complexity of
modern SoCs (System-on-Chips).

• Small/Medium Design: 5 to 15 clocks (e.g., core clock, peripheral clocks, memory

clock, test clock).
• Large SoC: 20 to 50+ clocks (including primary clocks, PLL outputs, and various
generated clocks for different IP blocks).

a. Any challenge/issue faced with constraint

The main challenges in multi-clock designs are:

15 Completeness of SDC: Ensuring every clock is defined and every I/O port is
constrained relative to its clock.
16 CDC Verification: The complexity of verifying data integrity across a large number
of asynchronous and synchronous clock domain boundaries.
17 Clock Grouping: Correctly identifying and constraining the relationships between all
clocks using set_clock_groups (asynchronous, logically exclusive, physically
exclusive) to avoid over-constraining or under-constraining the design.
18 Clock Latency and Skew: Managing the insertion delay and skew of a complex clock
tree network, especially when clocks are generated by multiple PLLs.

16. RTL-which will have higher precedence among parameter and

local parameter in Verilog?
The concept of "precedence" is slightly misleading here. parameter and localparam serve
different purposes regarding their visibility and modifiability:

• parameter: Can be overridden from outside the module during instantiation (using the
#(.PARAM_NAME(value)) syntax) or via defparam.
• localparam: Cannot be overridden from outside the module. Its value is fixed within
the module where it is defined.

If a module defines both a parameter and a localparam, they are simply two different constants.
However, if a localparam is defined using a value derived from a parameter, the localparam
will reflect the value of the parameter (which may have been overridden).

Precedence in Overriding: localparam has higher "fixity" or "precedence" in that its

value is final and cannot be changed by the user instantiating the module, unlike
parameter [2].

17. Exposure with Timing analyzer and Spyglass CDC goal

settings.
This question assesses the candidate's practical experience with two key tool categories:
 19 Timing Analyzer (e.g., Synopsys PrimeTime, Cadence Tempus): Experience
includes:
◦ Running the tool with SDC and netlist.
◦ Analyzing timing reports (setup/hold slack, critical paths).
◦ Debugging timing violations (identifying the failing cell, net, or constraint).
◦ Generating and interpreting reports on clock domains, clock skew, and path
delays.
20 SpyGlass CDC: Experience includes:
◦ Setting up the CDC environment (SGDC files).
◦ Selecting and running specific goals (Structural, Functional, Setup).
◦ Interpreting the CDC reports to find unsynchronized paths.
◦ Implementing and verifying synchronization schemes (e.g., 2-FF, MUX, FIFO).

18. Inputs needed to run lint check in spyglass (SGDC settings).

To run a lint check using SpyGlass (or any similar tool), the following inputs are typically
required:

21 RTL Source Files: The Verilog, VHDL, or SystemVerilog files that constitute the
design.
22 Top-Level Module Name: The name of the module to be analyzed.
23 Technology Libraries (Optional but Recommended): Libraries that define the
standard cells, allowing the tool to perform more accurate checks related to synthesis.
24 SpyGlass Design Constraints (SGDC) File: This is the configuration file for
SpyGlass. It contains:
◦ Tool Settings: Specifying the HDL version, the lint rule set to use (e.g.,
STARC, OpenMORE, or custom rules).
◦ Waivers: Listing specific violations that should be ignored, along with
justification.
◦ Design Environment: Defining parameters, defines, and search paths for the
RTL files.

19. Difference between local and global parameters in verilog.

In standard Verilog, the terms "local" and "global" are more accurately applied to localparam
and parameter (which can be globally overridden), or to the scope of parameter vs. define
(macro).

``define` (Global localparam (Module-

Feature parameter (Module-level)
Macro) level, Fixed)

Global scope (once defined,

it is visible everywhere Local to the module
Scope Local to the module definition.
after that point in the definition.
compilation).

Cannot be overridden
Can be overridden during Cannot be overridden
during instantiation. It is a
module instantiation during module
Modifiability text substitution that must
(#(.PARAM(value))) or via instantiation. Its value is
be changed in the source
defparam. fixed within the module.
file.
 ``define` (Global localparam (Module-
Feature parameter (Module-level)
Macro) level, Fixed)

Constants derived from

Configuration settings that need
Global constants or parameters or internal
to be customized for each
Use Case conditional compilation constants that should
instance (e.g., FIFO depth, bus
flags (e.g., ifdef DEBUG). never be changed from
width).
outside.

20. How to write constraints for create clock and generated clock?
The constraints are written using the SDC commands create_clock and
create_generated_clock.

A. create_clock (Primary Clock)

Used to define a clock that originates from an external source (e.g., a pin on the chip).

Syntax:

create_clock -name <clock_name> -period <period_value> [get_ports

<port_name>]

Example: A 100 MHz clock (10 ns period) on port CLK_IN.

create_clock -name CLK_100M -period 10.0 [get_ports CLK_IN]

B. create_generated_clock (Generated Clock)

Used to define a clock that is derived from an existing clock (the master clock) through logic
within the design (e.g., PLL, clock divider).

Syntax:

create_generated_clock -name <gen_clock_name> \

-source [get_pins <master_clock_pin>] \

-divide_by <factor> \

[get_pins <generated_clock_pin>]

Example: A clock divided by 2 (20 ns period) from CLK_100M at the output pin of a divider
U_DIV.

create_generated_clock -name CLK_50M \

-source [get_ports CLK_IN] \

-divide_by 2 \

[get_pins U_DIV/CLK_OUT]
The -source must point to the pin where the master clock is defined or where it enters the clock-
modifying logic.

References
[1] Synopsys. SpyGlass CDC: Clock Domain Crossing Verification. [Online]. Available:
[Link]
[Link]

[2] Stack Overflow. Difference between "parameter" and "localparam". [Online]. Available:
[Link]
localparam

[3] Synopsys. SpyGlass Lint: Early Design Analysis. [Online]. Available:

[Link]
[Link]

[4] VLSI Facts. Lint Check in VLSI Design: Common Linting Errors and How to Fix Them.
[Online]. Available: [Link]
and-how-to-fix-them/

21. Difference between logically exclusive and physically exclusive

clock groups.
This question was partially addressed in Q8, but here is a more focused comparison:

Logically Exclusive (-logically Physically Exclusive (-physically

Feature
exclusive) exclusive)

SDC
set_clock_groups -logically_exclusive set_clock_groups -physically_exclusive
Command

Physical Clocks can be physically active (running) Clocks cannot be active simultaneously. Only
State simultaneously on the chip. one clock is running at any given time.

The physical implementation (e.g., a clock

The design logic ensures that no functional
Functional MUX) ensures that only one clock is propagated,
data transfer occurs between the domains.
State making paths between them physically
Paths are functionally false.
impossible.

Two independent functional blocks (e.g., A design with two operating modes (Mode A
two separate IP cores) that share the same uses CLK_A, Mode B uses CLK_B), where a
Example
clock source but are never intended to clock multiplexer selects only one clock to drive
communicate data. the sequential logic.

STA ignores data path checks between the STA ignores data path checks between the
STA Action
domains. domains.
22. Asynchronous FIFO architecture (based on work experience).
An Asynchronous FIFO (First-In, First-Out) is a critical component used to safely transfer
data between two independent clock domains (Write Clock and Read Clock).

Core Architecture and Mechanism:

1 Dual-Port Memory: A memory array (usually a block RAM) that allows simultaneous
read and write operations.
2 Write Pointer (WP): A counter that tracks the next write location, clocked by the
Write Clock.
3 Read Pointer (RP): A counter that tracks the next read location, clocked by the Read
Clock.
4 Pointer Synchronization (The Key): The pointers must be safely transferred across
the clock domains to check for Full and Empty conditions.
◦ The Write Pointer is synchronized to the Read Clock domain to generate the
Empty flag.
◦ The Read Pointer is synchronized to the Write Clock domain to generate the
Full flag.
◦ Synchronization Technique: Typically, a Gray Code is used for the pointers.
Gray code ensures that only one bit changes at a time, which minimizes the risk
of meta-stability leading to an incorrect pointer value in the destination domain.
The synchronized Gray code is then converted back to binary for comparison.
5 Full/Empty Logic:
◦ Full: Occurs when the synchronized Read Pointer (in the Write Clock domain)
is one location behind the Write Pointer.
◦ Empty: Occurs when the synchronized Write Pointer (in the Read Clock
domain) is equal to the Read Pointer.

23. Experience on timing constraints for block level and system

level.
Block-Level Timing Constraints:

• Focus: Internal timing closure for the specific block (IP core).
• Constraints: Defined using virtual clocks for external I/O ports. The I/O delays
(set_input_delay, set_output_delay) are set relative to these virtual clocks, representing
the timing budget allocated to the block's interface.
• Goal: Ensure the block meets its internal frequency target and its interface timing
requirements, often specified in a timing budget document.

System-Level (Top-Level) Timing Constraints:

• Focus: End-to-end timing closure for the entire chip (SoC).

• Constraints: Defined using real clocks on the chip's primary I/O ports. The I/O delays
are set relative to the actual external components (e.g., DDR memory, external PHY).
• Goal: Verify that all paths, including those crossing block boundaries, meet the
required setup and hold times. This involves correctly defining clock groups
(set_clock_groups) and managing clock domain crossing exceptions (set_false_path).
24. Brief discussion on Spyglass cdc flow.
(This is a summary of Q11, emphasizing the key steps.)

The SpyGlass CDC flow is a static analysis methodology to verify the integrity of signals
crossing asynchronous clock domains. The flow involves:

6 Clock and Reset Definition: Providing accurate SDC files to define all clocks and
their relationships.
7 Structural Analysis: Identifying all CDC paths and classifying the synchronizers used
(e.g., 2-FF, MUX, FIFO).
8 Functional Verification: Checking the handshake protocols and control logic to ensure
safe data transfer.
9 Exception Management: Using the SpyGlass Design Constraints (SGDC) to waive
known false paths or to define custom synchronizers.
10 Reporting: Generating reports that highlight unsynchronized paths, potential meta-
stability issues, and bus synchronization failures, which must be fixed before tape-out.

25. Different lint errors.

Lint errors (or warnings) fall into several categories, indicating issues with code quality,
synthesis, or simulation:

Category Description Example Violation

Code constructs that are not

Unintended latch inference (missing else in
Synthesis Issues synthesizable or lead to inefficient
a combinational block).
hardware.

Code that behaves differently in Mixing blocking (=) and non-blocking (<=)
Simulation/RTL Issues simulation vs. synthesis, or causes assignments incorrectly; using delays (#) in
race conditions. synthesizable code.

Violations of company or industry Missing sensitivity list in an always block

Coding
standards (e.g., STARC, (pre-SystemVerilog); using hard-coded
Style/Portability
OpenMORE). numbers instead of parameters.

Issues related to module interfaces Unconnected input/output ports; multi-

Connectivity/Hierarchy
and connections. driver nets.

Improper handling of clock and Asynchronous reset removal not

Clock/Reset Issues
reset signals. synchronized; gated clocks.

26. How to ensure all the submodules/rtl files has been added to
spyglass cdc/lint hierarchy?
Ensuring complete hierarchy is crucial for accurate analysis. Methods include:

11 Automated File List Generation: Using a build system (e.g., Makefiles, scripts) to
automatically generate the list of all RTL files required by the top-level module.
12 Tool-Specific Configuration: SpyGlass uses a project file (often a Tcl script) where
the list of all source files and search paths is explicitly defined.
 13 Hierarchy Check Goal: Running a specific SpyGlass goal (often part of the Setup or
Lint goals) that checks the design hierarchy and reports any unresolved modules (black
boxes) or missing files.
14 RTL Elaboration: The tool performs an elaboration step, similar to a simulator, to
build the design's internal structure. If any module is missing, the elaboration will fail
or issue a warning about an undefined module.

27. How to verify the design based on parameters (based on work

experience)?
Verifying a parameterized design involves ensuring the design functions correctly across the
entire range of supported parameter values.

15 Testbench Parameterization: The testbench itself should be parameterized to match

the Device Under Test (DUT).
16 Configuration Files: Using a central configuration file (e.g., a SystemVerilog package
or a Tcl script) to define all parameter values.
17 Regression Testing: Running the full test suite with different parameter configurations
(e.g., minimum width, maximum width, typical width, different FIFO depths).
18 Formal Verification: Using formal tools (e.g., JasperGold) to prove properties
(assertions) are true for all possible parameter values, or for a defined range of values.
This is often more efficient than simulation for corner cases.

28. What are the constraints used in previous project

This is a personal experience question, but a comprehensive answer should cover the standard
SDC categories:

19 Clock Definition: create_clock for primary clocks and create_generated_clock for PLL
outputs and dividers.
20 I/O Constraints: set_input_delay and set_output_delay to model external components
(e.g., DDR memory interface).
21 Clock Grouping: set_clock_groups -asynchronous for independent clocks and
set_clock_groups -logically_exclusive for mode clocks.
22 Timing Exceptions: set_false_path for asynchronous resets and CDC paths, and
set_multicycle_path for paths that require more than one clock cycle.

29. What is the experience in the previous project?

This is a broad question intended to gauge the candidate's role and technical depth. A good
answer should briefly cover the entire design flow:

• RTL Design: (e.g., "I was responsible for the RTL design of the PCIe controller,
focusing on high-speed data path implementation.")
• Verification: (e.g., "I developed the UVM testbench components and achieved 100%
functional and code coverage.")
• Synthesis/STA: (e.g., "I performed synthesis using Design Compiler, managed the
SDC constraints, and closed timing on the block at 500 MHz.")
• Physical Design (Optional): (e.g., "I worked closely with the physical design team to
resolve floorplanning and clock tree synthesis issues.")
30. What is Synthesis?
Synthesis is the process of converting an abstract description of a digital circuit, typically
written in a Hardware Description Language (HDL) like Verilog or VHDL (RTL), into a
technology-specific gate-level netlist.

Key Steps:

23 Translation: The HDL code is translated into a generic netlist of basic logic elements
(AND, OR, NOT, Flip-Flops).
24 Mapping: The generic netlist is mapped to the specific standard cells available in the
target technology library (e.g., 28nm, 7nm).
25 Optimization: The tool optimizes the netlist to meet the constraints specified in the
SDC file, primarily focusing on:
◦ Timing: Meeting the required clock frequency (setup/hold).
◦ Area: Minimizing the number of gates used.
◦ Power: Reducing dynamic and static power consumption.

Output: A gate-level netlist (e.g., in Verilog format) and a set of timing, area, and power
reports. This netlist is the input for the subsequent Place and Route (Physical Design) stage.

References
[1] Intel. Exclusive Clock Groups. [Online]. Available:
[Link]
[Link]

[2] VLSI Verify. Asynchronous FIFO. [Online]. Available:

[Link]

[3] LinkedIn. Key Challenges in RTL Synthesis and How to Overcome. [Online]. Available:
[Link]

[4] Synopsys. SpyGlass CDC: Clock Domain Crossing Verification. [Online]. Available:
[Link]
[Link]

31. What are the issues faced during Synthesis?

Synthesis is a complex process, and engineers frequently encounter issues that must be resolved
before proceeding to physical design. Common issues include:

1 Timing Violations (Setup/Hold): The most common issue. The synthesized netlist
cannot meet the required clock frequency (period) specified in the SDC.
◦ Fixes: Relaxing constraints, optimizing RTL (reducing logic depth), using
faster cells (upsizing), or restructuring the design.
 2 Unintended Latch Inference: The RTL code implies memory elements (latches)
where none were intended, usually due to incomplete if-else or case statements in
combinational logic. Latches are generally avoided in synchronous design due to STA
complexity.
◦ Fixes: Ensuring all branches of conditional logic are covered, or explicitly
assigning a default value to the output.
3 Non-Synthesizable Constructs: Using Verilog constructs that cannot be mapped to
physical hardware (e.g., #delay, initial blocks, force/release).
◦ Fixes: Removing or replacing non-synthesizable code with equivalent structural
or behavioral code.
4 Constraint Issues (SDC): Missing, incomplete, or conflicting SDC constraints,
leading to the tool either over-constraining (making timing closure impossible) or
under-constraining (resulting in a slow design).
◦ Fixes: Using constraint validation tools and thorough SDC review.
5 Area/Power Overruns: The synthesized design exceeds the allocated area or power
budget.
◦ Fixes: Applying area/power optimization goals during synthesis, or redesigning
the RTL for efficiency.

32. Difference between Local and Global variable?

This concept, originating from software programming, applies to hardware design in the
context of scope and accessibility, particularly when discussing parameters and signals.

Feature Local Variable (or Signal/Parameter) Global Variable (or Signal/Macro)

Visible and accessible only within the block

Visible and accessible throughout the
Scope (function, task, module, or specific code
entire program or design hierarchy.
block) where it is declared.

Exists only while the block is executing (in

Exists for the entire duration of the
Lifetime software) or during the module's instantiation
program/design.
(in hardware).

Verilog ``define` macros (global text

Hardware Signals declared within a module; localparam
substitution); signals explicitly declared in
Equivalent in Verilog.
a top-level module and passed down.

Key Prevents unintended side effects and improves Provides universal access to critical
Advantage code modularity and reusability. constants or control signals.

33. Explain constant propagation in design compiler

Constant Propagation is a fundamental optimization technique performed by synthesis tools
like Synopsys Design Compiler (DC).

Mechanism: The tool identifies signals or sequential elements (Flip-Flops) whose values are
determined to be constant (always '0' or always '1') throughout the design's operation.

Optimization Steps:
 6 Identification: DC analyzes the RTL and identifies any logic that feeds a constant
value.
7 Replacement: The tool replaces the constant-valued signal or FF with the actual
constant value (VCC or GND).
8 Logic Simplification (Pruning): Any logic gates that had the constant as an input are
simplified or removed entirely. For example, an AND gate with one input tied to '0' will
be replaced by a direct connection to '0' (the output is always '0'), and the AND gate is
removed.
9 Area/Power Reduction: This simplification reduces the total number of gates, leading
to smaller area and lower power consumption.

Example: If a parameter DATA_WIDTH is set to 8, and a 16-bit register is only using the
lower 8 bits, DC can propagate the constant '0' to the upper 8 bits and prune the unused logic.

34. What were the lint errors faced in previous project?

This is an experience-based question. A strong answer should mention specific, high-impact
lint errors and how they were resolved:

10 Unintended Latch Inference: (As mentioned in Q31) Caused by incomplete

conditional statements. Resolution: Added default assignments or complete else
clauses.
11 Missing Sensitivity List: In older Verilog, forgetting to include all combinational
inputs in the always block sensitivity list, leading to simulation-synthesis mismatch.
Resolution: Switched to using always @* (or always_comb in SystemVerilog) for all
combinational logic.
12 Multi-Driver Net: Two different sources driving the same wire, leading to an X-state
in simulation and potential short circuits in hardware. Resolution: Restructured the
logic to use a multiplexer (MUX) or tri-state buffers.
13 Blocking vs. Non-Blocking Mismatch: Using blocking assignments (=) for sequential
logic or non-blocking assignments (<=) for combinational logic. Resolution: Enforced
the rule: Blocking for Combinational, Non-Blocking for Sequential.

35. Question related to lint example

(This question is too vague to answer directly, but a good response would be to provide a
concrete example of a lint rule and its benefit.)

Example: Rule - Avoid Gated Clocks

• Violation: Using a combinational logic gate (e.g., AND gate) to turn a clock signal ON
or OFF.
• Reason for Lint Rule: Gated clocks introduce severe clock skew and glitches, making
STA unreliable and potentially causing functional failures (e.g., hold violations).
• Recommended Fix: Replace the gated clock with a Clock Enable (CE) signal that
feeds the data input of the Flip-Flop, allowing the clock to run continuously.
36. What are the different lint errors
(This is a duplicate of Q25, but can be answered by listing the categories again for
completeness.)

Lint errors are broadly categorized as:

14 Synthesizability Errors: Code that cannot be mapped to hardware (e.g., initial, real
data types).
15 Simulation-Synthesis Mismatch Errors: Code that simulates differently from how it
synthesizes (e.g., incorrect use of blocking/non-blocking assignments).
16 Design Quality Errors: Issues that lead to poor hardware implementation (e.g.,
unintended latches, multi-driver nets, asynchronous reset removal).
17 Coding Style Errors: Violations of readability and maintainability standards (e.g.,
missing comments, improper naming conventions).

37. Input required to run synthesis and lint

The inputs required for both Synthesis and Linting are largely the same, with a few key
differences:

Input Type Synthesis (e.g., Design Compiler) Linting (e.g., SpyGlass Lint)

Design Files RTL Source Files (Verilog/VHDL) RTL Source Files (Verilog/VHDL)

SDC (Synopsys Design Constraints) file SGDC (SpyGlass Design Constraints)

Constraints
(Timing goals) file (Rule sets, waivers)

Technology Technology Library (Standard cell Optional (Used for more accurate
Data definitions, timing/power data) synthesis-related checks)

Top-Level Top-level module name Top-level module name

38. Can we use multi cycle path for reset

No, a multi-cycle path constraint (set_multicycle_path) should generally NOT be used for
a reset signal.

Reasoning:

18 Reset is Asynchronous/Synchronous: A reset signal is typically constrained as either

an asynchronous signal (using set_false_path or proper reset synchronization) or a
synchronous signal (checked for setup/hold in one cycle).
19 Multi-Cycle Path Purpose: set_multicycle_path is used for data paths that are
intentionally designed to take more than one clock cycle to settle (e.g., a complex
arithmetic operation). It relaxes the setup check to $N$ cycles and the hold check to
$N-1$ cycles.
20 Reset Timing: The reset signal must propagate to all sequential elements within a
single clock cycle (or be properly synchronized) to ensure the entire design is reset
reliably and simultaneously. Relaxing the timing on the reset path using
 set_multicycle_path would allow the reset signal to take multiple cycles to reach
different parts of the design, leading to asynchronous reset removal issues and
potential functional failures.

Correct Constraint for Reset:

• Asynchronous Reset: Use set_false_path on the path from the reset source to the flip-
flop data inputs (since the reset pin is used).
• Synchronous Reset: The reset signal is treated as a normal data signal and must meet
the single-cycle timing requirements.

References
[1] LinkedIn. Key Challenges in RTL Synthesis and How to Overcome. [Online]. Available:
[Link]

[2] GeeksforGeeks. Constant Propagation in Compiler Design. [Online]. Available:

[Link]

[3] Synopsys. Design Compiler Optimization Reference Manual. [Online]. Available:

[Link]

[4] VLSI Talks. SYNTHESIS. [Online]. Available: [Link]

design/synthesis/