Edge detector design in VHDL - Time & Space Complexity
We want to understand how the time needed to detect edges changes as the input signal size grows.
How does the design handle more input bits or longer signals?
Analyze the time complexity of the following code snippet.
process(clk)
begin
if rising_edge(clk) then
prev_signal <= signal_in;
edge_detected <= signal_in and not prev_signal;
end if;
end process;
This code detects a rising edge by comparing the current input with its previous value on each clock cycle.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: The process runs once every clock cycle.
- How many times: It repeats for each clock tick, processing one input bit at a time.
Each clock cycle handles one input bit, so the total work grows directly with the number of bits.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 clock cycles |
| 100 | 100 clock cycles |
| 1000 | 1000 clock cycles |
Pattern observation: The time grows linearly as input size increases.
Time Complexity: O(n)
This means the time to detect edges grows in direct proportion to the number of input bits.
[X] Wrong: "The edge detector checks all bits at once, so time does not grow with input size."
[OK] Correct: The design processes one bit per clock cycle, so more bits mean more cycles and more time.
Understanding how hardware designs scale with input size helps you explain efficiency clearly and confidently.
"What if we changed the design to process multiple bits in parallel? How would the time complexity change?"
Practice
Solution
Step 1: Understand the role of edge detectors
Edge detectors monitor signals to find when they change state, either rising or falling edges.Step 2: Identify the correct function
Detecting changes in signal levels is exactly what edge detectors do, unlike storing values or generating clocks.Final Answer:
To detect changes in a signal from low to high or high to low -> Option DQuick Check:
Edge detection = signal change detection [OK]
- Confusing edge detection with clock generation
- Thinking edge detectors store constant values
- Assuming edge detectors convert signal types
Solution
Step 1: Identify correct signal declaration for previous value
For edge detection, we store the previous signal value as a signal of type std_logic.Step 2: Compare options
signal prev_signal : std_logic; declares a signal of type std_logic, suitable for storing previous signal state. Variables or constants are not appropriate here.Final Answer:
signal prev_signal : std_logic; -> Option BQuick Check:
Previous value storage = signal std_logic [OK]
- Using variable instead of signal for previous value
- Declaring constant instead of signal
- Using incorrect data types like integer
process(clk)
begin
if rising_edge(clk) then
prev_signal <= signal_in;
if signal_in = '1' and prev_signal = '0' then
edge_detected <= '1';
else
edge_detected <= '0';
end if;
end if;
end process;
What will be the value of
edge_detected if signal_in changes from '0' to '1' at the clock edge?Solution
Step 1: Understand signal update timing in VHDL
In VHDL, signal assignments inside a clocked process update after the process ends, so prev_signal still holds old value during evaluation.Step 2: Evaluate condition at clock edge
At the clock edge, prev_signal still equals '0' (old value), signal_in is '1'. prev_signal <= signal_in schedules update after process. Condition signal_in='1' and prev_signal='0' is true, so edge_detected <= '1'.Final Answer:
'1' -> Option CQuick Check:
Signal update delay enables edge detection with old prev_signal [OK]
- Assuming prev_signal updates immediately within process
- Confusing signal and variable assignment timing
- Thinking edge_detected remains '0' due to update order
process(clk)
begin
if rising_edge(clk) then
prev_signal <= signal_in;
if signal_in = '0' and prev_signal = '1' then
edge_detected <= '1';
else
edge_detected <= '0';
end if;
end if;
end process;
Solution
Step 1: Analyze signal update order
Due to VHDL signal semantics, prev_signal retains its prior value ('1') during the condition check even though assigned first, allowing correct falling edge detection when signal_in='0'.Step 2: Confirm code correctness
This is the standard implementation for a synchronous falling edge detector; no error exists.Final Answer:
No error; code is correct -> Option AQuick Check:
Standard order works due to delta-delay updates [OK]
- Misunderstanding that assignment order requires swapping
- Using rising_edge on signal_in instead of clk
- Declaring prev_signal as variable
signal_in. Which approach correctly implements this?Solution
Step 1: Understand dual edge detection logic
Detecting both edges means detecting any change in signal_in compared to its previous value.Step 2: Implement comparison and update order
Comparing current and previous values with signal_in /= prev_signal detects any edge. Updating prev_signal after ensures correct timing.Final Answer:
Compare current and previous values: edge_detected <= '1' when signal_in /= prev_signal else '0'; update prev_signal after -> Option AQuick Check:
signal_in /= prev_signal detects any edge [OK]
- Using separate clocks for edge detection
- Ignoring previous signal value
- Assigning edge_detected based only on current signal
Ready to prove it?
Pass the test and this pattern moves unknown
