Synthesis Attributes and Constraints

1. Engineering intuition — guide, or require

Two questions need two different tools. "Build this part this particular way" — keep this signal, make this array a block RAM, encode this FSM one-hot — is guidance, and it lives as an attribute right on the object in your RTL. "This design must run at 200 MHz; this path crosses clocks; ignore that path" is a requirement, and it lives in a separate constraints file the timing engine reads. Attributes change how the tool implements; constraints tell the tool what it must achieve and how to analyze timing. Confusing them is a classic mistake — you cannot make a design faster by adding attributes, and you cannot force a RAM style with a timing constraint. Reach for guidance when inference is wrong; reach for constraints to state the timing contract.

2. Formal explanation — attributes (RTL) vs constraints (SDC/XDC)

-- ATTRIBUTES live IN the RTL and GUIDE implementation (vendor-specific names/values).
-- Mechanism: declare the attribute, then apply it to an object.
attribute ram_style : string;
attribute ram_style of mem : signal is "block";        -- force BLOCK RAM (vs "distributed")
 
attribute keep : string;
attribute keep of debug_sig : signal is "true";        -- PRESERVE a signal the optimizer would remove
 
attribute fsm_encoding : string;
attribute fsm_encoding of state : signal is "one_hot";  -- choose FSM state ENCODING
 
attribute async_reg : string;
attribute async_reg of sync_ff : signal is "true";      -- mark CDC synchronizer FFs (placement/timing)

# CONSTRAINTS state the timing REQUIREMENTS the tool must meet.
create_clock -name clk -period 5.000 [get_ports clk]      ;# define a 200 MHz clock
set_input_delay  -clock clk 1.0 [get_ports data_in]       ;# I/O timing
set_false_path   -from [get_clocks clkA] -to [get_clocks clkB]   ;# don't time this CDC path

Attributes are RTL annotations that guide the tool (RAM style, keep, FSM encoding, async_reg); declared with attribute NAME : type; then attribute NAME of obj : signal is value;. Constraints are a separate SDC/XDC file stating requirements (clock periods, I/O timing, false/multicycle paths). Guidance vs requirement — different mechanisms, different files.

3. Production usage — directing implementation and stating timing

-- USE AN ATTRIBUTE when inference/style can't express your intent:
--   • optimizer removed a signal you need to probe        → keep / dont_touch
--   • a memory inferred the WRONG style (LUTRAM vs BRAM)  → ram_style / rom_style
--   • you want a specific FSM encoding                    → fsm_encoding (one_hot/gray/sequential)
--   • CDC synchronizer FFs need marking                   → async_reg
--   • control fanout / preserve hierarchy                 → max_fanout / keep_hierarchy
 
-- USE A CONSTRAINT to state timing the design MUST meet (in SDC/XDC, not RTL):
--   • every clock's period/frequency                      → create_clock
--   • board/interface I/O timing                          → set_input_delay / set_output_delay
--   • paths to exclude or relax                           → set_false_path / set_multicycle_path
-- Constraints drive timing ANALYSIS and optimization toward Fmax (16.6); without them, timing is meaningless.

What hardware does this become? Attributes nudge what synthesis builds — the same RTL with ram_style => "block" lands in block RAM instead of LUTs; fsm_encoding => "one_hot" changes the state register's encoding; keep stops a signal being optimized away. Constraints build no hardware — they define the timing contract the tool optimizes toward and checks against (a design with no create_clock has no meaningful timing at all). Both are largely vendor-specific (Xilinx/AMD, Intel/Altera differ), so they live at the edges of portability — use them only where inference and coding style genuinely cannot express the intent.

4. Structural interpretation — RTL plus attributes plus constraints

5. Why this is structural, not timing

Attributes and constraints are directives to the tool — guidance embedded in the source and requirements in a constraints file — so the structure above (two inputs steering synthesis) is the right picture, not a waveform. Attributes change the implementation structure (which RAM, which encoding, which signals survive); constraints define the contract and how timing is analyzed, not a behavior over time. Neither is a signal trace; both are design-time mechanisms for directing how the netlist is built and judged, which is exactly why they are shown as structure.

6. Debugging example — using the wrong mechanism (or none)

Expected: the design hits its target — right memory type, right speed. Observed (a): an array inferred as LUT RAM when block RAM was intended, or a needed debug signal optimized away. Observed (b): timing "passes" but the chip fails in the lab, or the tool reports no timing paths. Root cause (a): inference chose the wrong implementation and no attribute directed it (ram_style, keep). Root cause (b): there were no timing constraints — no create_clock/I/O timing — so the tool had nothing to meet and timing analysis was vacuous; or someone tried to fix timing with an attribute instead of a constraint. Fix: use an attribute to direct implementation (force ram_style, keep the signal, set fsm_encoding); use a constraint to state requirements (create_clock every clock, I/O delays, false/multicycle paths) so timing analysis is meaningful. Engineering takeaway: attributes guide how the design is built; constraints state what timing it must meet — use the right mechanism, and never ship without proper clock constraints.

# BUG: no clock constraint → timing analysis is meaningless; "passing" timing proves nothing.
# FIX: define every clock (and I/O / exceptions) so the tool has a real contract to meet.
create_clock -name clk -period 5.000 [get_ports clk]   ;# 200 MHz target

7. Common mistakes & what to watch for

• Confusing attributes with constraints. Attributes guide implementation (in RTL); constraints state timing (SDC/XDC) — use the right one for the job.
• No clock constraints. Without create_clock (and I/O timing), timing analysis is meaningless; always constrain every clock.
• Over-using attributes. Prefer inference and coding style; reach for attributes only where they genuinely cannot express the intent.
• Ignoring vendor specificity. Attribute/constraint names differ across Xilinx/AMD and Intel/Altera; they hurt portability — isolate them.
• Forcing timing with attributes. You cannot make a path meet timing with an attribute; fix the path (pipeline/logic depth, 16.6) and constrain it correctly.

8. Engineering insight & continuity

Attributes and constraints are how you direct the tool when inference and style are not enough: attributes in the RTL guide implementation (keep, RAM style, FSM encoding, CDC marking), while constraints in a separate SDC/XDC file state the timing requirements the tool must meet (clocks, I/O, false/multicycle paths). Guidance versus contract — different mechanisms, used sparingly because they are vendor-specific. This rounds out the practical synthesis toolkit. The module closes by looking at how the modern language standard improves synthesis itself: the next lesson, VHDL-2008 for Synthesis, covers the 2008 features — process(all), unconstrained records, simplified packages — that make synthesizable RTL cleaner and safer.