Resource inference rules in VHDL - Cheat Sheet & Quick Revision

Recall & Review

beginner

What does resource inference mean in VHDL?

Resource inference is when the VHDL compiler automatically decides which hardware components (like flip-flops or multiplexers) to create based on your code, without you explicitly specifying them.

beginner

Which VHDL construct typically leads to flip-flop inference?

Using a process with a clock edge condition (e.g., if rising_edge(clk)) and assigning values inside it usually causes the compiler to infer flip-flops.

beginner

How does the VHDL compiler infer a combinational logic resource?

When you write concurrent assignments or processes without clock edges and assign outputs based on inputs, the compiler infers combinational logic like gates or multiplexers.

intermediate

What is a common cause of unintended latch inference in VHDL?

If a process does not assign a value to a signal in all possible conditions, the compiler infers a latch to remember the previous value, which may cause timing issues.

intermediate

Why is understanding resource inference important when writing VHDL code?

Because it helps you write code that maps efficiently to hardware, avoids unintended components like latches, and ensures your design works as expected on the chip.

Which VHDL statement usually causes flip-flop inference?

A A concurrent signal assignment

B A variable assignment inside a function

C A process without clock conditions

D A process with a clock edge condition

Flip-flops are inferred when a process uses a clock edge condition like 'if rising_edge(clk)'.

What happens if a signal is not assigned in all branches of a process?

A A latch is inferred

B A flip-flop is inferred

C Combinational logic is inferred

D An error is generated

Missing assignments in some branches cause latch inference to hold the previous value.

Which resource is inferred by concurrent signal assignments without clock edges?

A Latches

B Flip-flops

C Combinational logic

D Memory blocks

Concurrent assignments without clock edges infer combinational logic like gates.

Why should you avoid unintended latch inference?

A It can cause unpredictable timing and bugs

B It reduces power consumption

C It improves design readability

D It increases clock speed

Unintended latches can cause timing problems and make the design unreliable.

What is the main benefit of resource inference in VHDL?

A Writing code without syntax rules

B Automatically mapping code to hardware components

C Avoiding the use of signals

D Running code faster on a computer

Resource inference helps the compiler decide which hardware parts to create from your code.

Explain how VHDL infers flip-flops and what coding style triggers this inference.

Think about how you write synchronous logic in VHDL.

Describe what causes latch inference in VHDL and why it can be problematic.

Consider what happens if a signal keeps its old value unintentionally.

Practice

1. Which VHDL construct typically causes the compiler to infer a register (flip-flop)?

easy

A. A clocked process with a rising_edge(clock) condition

B. A simple concurrent signal assignment

C. A combinational process without clock sensitivity

D. A constant declaration

Solution

1. Step 1: Understand what infers registers

   Registers (flip-flops) are inferred when signals are assigned inside a process triggered by a clock edge, such as rising_edge(clock).

2. Step 2: Identify the correct construct

   A clocked process with rising_edge(clock) matches this condition, so it infers registers.

3. Final Answer:

   A clocked process with a rising_edge(clock) condition -> Option A

4. Quick Check:

   Clocked process = register inference [OK]

Hint: Registers come from clocked processes with edge checks [OK]

Common Mistakes:

• Confusing combinational assignments with registers
• Thinking constants infer registers
• Ignoring the clock edge condition

2. Which of the following VHDL code snippets correctly infers combinational logic?

easy

A. q <= a and b;

B. signal r : std_logic_vector(3 downto 0);

C. constant c : integer := 5;

D. process(clk) begin if rising_edge(clk) then q <= d; end if; end process;

Solution

1. Step 1: Identify combinational logic inference

   Combinational logic is inferred from concurrent signal assignments or processes without clock edges.

2. Step 2: Check each option

   q <= a and b; is a concurrent assignment using logical AND, which infers combinational logic.

3. Final Answer:

   q <= a and b; -> Option A

4. Quick Check:

   Concurrent assignment = combinational logic [OK]

Hint: Combinational logic comes from simple concurrent assignments [OK]

Common Mistakes:

• Choosing clocked processes for combinational logic
• Confusing constants or signals with logic inference
• Ignoring the absence of clock edges

3. Given the following VHDL code, what hardware resource is inferred?

process(clk, a, b)
begin
  if rising_edge(clk) then
    q <= a or b;
  end if;
end process;

medium

A. Combinational logic only

B. Register (flip-flop) with combinational logic inside

C. Constant value

D. Latch

Solution

1. Step 1: Analyze the process sensitivity and clock usage

   The process is sensitive to clk, a, and b, but the assignment happens only on rising_edge(clk), indicating a clocked process.

2. Step 2: Determine inferred hardware

   Because the assignment is inside a clock edge condition, a register (flip-flop) is inferred. The expression 'a or b' is combinational logic feeding the register input.

3. Final Answer:

   Register (flip-flop) with combinational logic inside -> Option B

4. Quick Check:

   Clock edge + logic = register with combinational input [OK]

Hint: Clock edge inside process means register inferred [OK]

Common Mistakes:

• Ignoring the clock edge and thinking it's pure combinational
• Confusing latch with register
• Assuming constants are inferred

4. Identify the error in this VHDL code that prevents correct resource inference:

process(clk)
begin
  if clk = '1' then
    q <= d;
  end if;
end process;

medium

A. Signal q is not declared

B. Process sensitivity list is empty

C. Missing rising_edge(clk) condition for clocked process

D. Constant d is used instead of signal

Solution

1. Step 1: Check clock condition usage

   The process uses 'if clk = '1'' instead of 'if rising_edge(clk)', which is the standard way to infer registers.

2. Step 2: Understand impact on resource inference

   Without rising_edge(clk), the compiler may infer a latch or incorrect hardware instead of a register.

3. Final Answer:

   Missing rising_edge(clk) condition for clocked process -> Option C

4. Quick Check:

   Use rising_edge(clk) for registers [OK]

Hint: Always use rising_edge(clk) for registers [OK]

Common Mistakes:

• Using level-sensitive clock check instead of edge
• Ignoring sensitivity list correctness
• Assuming signal declarations cause inference errors

5. You want to infer a 4-bit register with asynchronous reset in VHDL. Which code snippet correctly follows resource inference rules?

hard

A. process(reset) begin if reset = '1' then q <= (others => '0'); end if; end process;

B. process(clk) begin if rising_edge(clk) then if reset = '1' then q <= (others => '0'); else q <= d; end if; end if; end process;

C. q <= d when reset = '0' else (others => '0');

D. process(clk, reset) begin if reset = '1' then q <= (others => '0'); elsif rising_edge(clk) then q <= d; end if; end process;

Solution

1. Step 1: Identify asynchronous reset structure

   An asynchronous reset requires the reset signal in the sensitivity list and a separate if condition before the clock edge check.

2. Step 2: Check each option for correct inference

   process(clk, reset) begin if reset = '1' then q <= (others => '0'); elsif rising_edge(clk) then q <= d; end if; end process; has reset and clk in sensitivity list, checks reset first, then rising_edge(clk), correctly inferring a register with async reset.

3. Final Answer:

   process(clk, reset) begin if reset = '1' then q <= (others => '0'); elsif rising_edge(clk) then q <= d; end if; end process; -> Option D

4. Quick Check:

   Async reset in sensitivity + if reset first = correct [OK]

Hint: Async reset must be checked before clock edge in process [OK]

Common Mistakes:

• Placing reset check inside clock edge condition (sync reset)
• Missing reset in sensitivity list for async reset
• Using conditional assignments outside process for registers