CHAPTER 6

Design of Counters-PART I
Asynchronous Vs Synchronous Counters
Basic Structure
• Built by cascading a few flip-flops.

• Figure shows an up counter using four T flip-flops.

• Up counter counts from 0 to 15 (4-bit counter).

• T flip-flops are simpler to use for counters than D flip-flops.

T Flip Flop

T = Toggle; has one input (T) and a clock.

Output = Q, Q̅ (Q bar).
Characteristic table:
• T = 0 → Q remains unchanged.

• T = 1 → Q toggles on each positive clock edge.

Operation of T Flip-Flop
• If Q = 0 and T = 1, on clock edge → Q becomes 1.

• Next clock → Q = 0 again.

• Continues toggling as long as T = 1.

Cascading T Flip-Flops
• Asynchronous counter uses 4 T flip-flops cascaded.

• Counter counts from 0 to 15.

• Adding more flip-flops increases count range:

o 5 flip-flops → counts 0 to 31.

Why "Asynchronous"?
• Each flip-flop’s clock input is driven by the output (Q̅ ) of the previous stage.
• So, clocks receive different signals.

• Flip-flops not synchronized with same clock → asynchronous.

T Flip-Flop Module
• Inputs: clk, t, reset.
• Output: q.
• Implemented behaviorally:
o Always block on posedge clk or reset.

o If reset is active → Q = 0.

o Else if t = 1 → Q = ~Q (toggle).

o Else → Q = Q (no change).

Clock-to-Q Delay (C2Q Delay)

• Added for simulation only.

• Flip-flops have delay from clock edge to output update.

• C2Q simulates this physical delay (~2ns here).

• Delay applied between next value computation and actual register update.
 Asynchronous Up Counter Module
• Inputs: clk, reset.

• Output: 4-bit counter.

• Instantiates 4 T flip-flops.

• Q̅ output of one flip-flop feeds clock of the next.

• Asynchronous counters trigger each flip-flop with the output

of the previous one, not the main clock.
• A reset signal is needed to initialize all flip-flops to zero at

the start.
• The example uses a 4-bit asynchronous up counter made

using T flip-flops.
• In the simulation:

o A clock is created with a 10 ns period (100 MHz).

o A reset pulse of 2 ns initializes all flip-flops.

o The counter runs for 200 ns, counting from 0 to 15, then wraps around to 0 again.

Problems in Asynchronous Counters

• The time each number is held is inconsistent (e.g., ‘1’ lasts 10 ns, ‘2’ lasts 8 ns).

• Glitches occur due to propagation delay in the flip-flops:

o Example: Output jumps from 0 → 1 → 0 → 2 instead of smooth progression.

• These glitches are because the delay accumulates as the output ripples through each

stage.
• Even small clock-to-Q delays (like 2 ns) can cause visible glitches in waveform.

• As more flip-flops toggle, the ripple causes larger delays (e.g., 4 flip-flops × 2 ns = 8

ns).
What If Delays Increase?
Figure below shows simulation with 2ns delay

• When clock-to-Q delay is increased to 6 ns, the max delay becomes 6 × 4 = 24 ns

Figure below shows simulation with 6ns delay

• If this is longer than the clock period (10 ns), the counter fails:
o The output sequence becomes incorrect (e.g., skipping from 3 → 0, missing 4).

• This proves asynchronous counters are not reliable in high-speed circuits.

Synchronous Counters: A Better Alternative
• In synchronous counters, all flip-flops are triggered by the same clock edge.

• This avoids ripple delays and ensures glitch-free, accurate outputs.

• A 4-bit synchronous up counter uses:

o T flip-flops.

o AND gates to generate toggle conditions based on previous outputs.

Working of the Synchronous Counter

• Initially: All outputs = 0 (0000).

• Clock pulse 1: First flip-flop toggles (Q0 = 1).

• Clock pulse 2: Both Q0 and Q1 toggle → result = 0010.

• Clock pulse 3: Toggle continues based on logic → 0011, 0100…

• Every flip-flop updates simultaneously, so no propagation delay between stages.

• Simulation shows clean transitions from one number to the next.

Building the Synchronous Counter in Vivado
• The design uses T flip-flops, each triggered by the same clock.

• Each flip-flop has an AND gate in front to determine if it should toggle.

• Assign statements are used in Verilog to describe the AND logic conditions.

• Example:

o assign T1 = Q0 & enable;

o This means the second flip-flop (Q1) toggles only if Q0 is high and enable is active.
Simulation and Delay Testing
• The simulation uses a clock period of 10 ns and flip-flop delays of 2 ns.

• Output:

o Counts from 0 → 1 → 2 → ... → 15 without any glitches.

o Every number stays for exactly 10 ns, proving smooth operation.

• When delay is increased to 6 ns:

o Still works because all flip-flops get the same clock and their delays don’t

accumulate.
o The only visible change is a slight shift in when the output settles (e.g., at 11 ns

instead of 10), but the values are correct.

Important Note on Delay and Critical Path

• Even though synchronous counters don’t have glitches, they still have a critical path:

o This is the path from input to output that takes the longest time (e.g., through

multiple AND gates).

o The delay in this path limits the maximum clock frequency the counter can

operate at.
• For example:

o Q3 might depend on Q2 & Q1 & Q0.

o These AND operations can slow things down slightly.

When to Use Which?

• Use Synchronous Counters:
o In high-speed applications.
o When glitch-free operation is crucial (e.g., in digital communication, processors).
o For accurate and reliable timing.
• Use Asynchronous Counters:
o When simplicity or low power is more important than speed.
o In slow applications like user-facing displays or manual counters.
o If glitches and tiny delays don’t affect your application.
UP DOWN LOAD COUNTERS

Types of Counters & Behavioral Modeling

• Multiple types of counters exist, each with different functionalities.

• Counters can be built using structural modeling (gates, muxes), but it’s tedious.

• Behavioral modeling is preferred for simplicity and clarity.

• Focus is on synchronous counters to avoid glitches.

General Synchronous Counter Design Pattern
1. Separate logic into:
o Memory component (register)

o Next state logic (combinational)

o Output logic

2. Follow standard synchronous coding guidelines.

3. Register handles state transitions on clock edge.
4. Next-state logic determines what the next value will be.
5. Output logic determines what is shown as output (often the current state).

General Synchronous Counter Design Pattern

1. Separate logic into:
o Memory component (register)

o Next state logic (combinational)

o Output logic

2. Follow standard synchronous coding

guidelines.
3. Register handles state transitions on clock
edge.
4. Next-state logic determines what the next
value will be.
5. Output logic determines what is shown as
output (often the current state).
6.
Up Counter Design (Generic Width)
• Parameterized 4-bit counter (default) →
counts from 0 to 15.
• Takes clk and reset_n inputs; outputs q.

• Code structure:

o Declare register: reg [BITS-1:0] q_reg, q_next;

o always @(posedge clk or negedge reset_n) → handles state
update.
▪ If reset is active, set q_reg to 0.

▪ Else, assign q_reg = q_next;

o always @(*) → combinational logic: q_next = q_reg + 1;

o Output logic: assign q = q_reg;
Testbench for Up Counter
• Clock runs continuously.
• Reset applied for 2ns, then released.
• Simulation runs for 200ns.
• Result: clean count from 0 to 15 (no glitches due to synchronicity).
• Can extend to 5 bits → counts from 0 to 31.
Down Counter Modification
• Only next state logic changes.

• Instead of q_next = q_reg + 1; use q_next = q_reg - 1;

Up-Down Counter with Enable

• Adds two inputs:
o enable: activates counting

o up: decides direction (up/down)

• Register logic:
o Update q_reg only if enable is asserted.

o Else keep q_reg same.

• Next state logic:

o If up == 1: q_next = q_reg + 1;

o Else: q_next = q_reg - 1;

o Fallback: q_next = q_reg; (to avoid inferred latches)

• Output logic unchanged: assign q = q_reg;

 \

Testbench for Up-Down Counter

• Clock and reset handled similarly.

• Initially, enable is 0 → no count.

• Later, enable = 1, up = 1 → counts up.

• After reaching 15, enable = 0 → holds value.

• Then, up = 0, enable = 1 → counts down.

Up-Down-Load Counter (UDL)

• Basic Behavior:
• Counter keeps its value if not enabled.
• When counting down (up = 0) and enabled, it counts down to 0, wraps to 15
(assuming 4-bit), and continues.
• It supports up, down, and parallel load functionalities.
Additional inputs:
o load: when asserted, loads value from d.

o d: value to be loaded.

• Inputs: clk, reset_n, enable, up, load, d

• Outputs: q

• Register and output logic same as up-down counter.

Counter Behavior:
• When load = 1: counter loads value d regardless of up.
• When load = 0 and up = 1: counts up (q_next = q_reg + 1).
• When load = 0 and up = 0: counts down (q_next = q_reg - 1).
• If none of the above conditions, q_next = q_reg (no change).
Next State Logic Implementation:
• Implemented using casex on {load, up} (2-bit control signal).
• Match cases:
o 2'b00: down count → q_next = q_reg - 1

o 2'b01: up count → q_next = q_reg + 1

o 2'b1x: load → q_next = d

o default: q_next = q_reg (no change)

• Use casex to treat x as don't-care when matching.

Code Structure:
• Three always blocks:
1. Register Block: Handles clock and reset
behavior.
2. Next State Logic: Determines the value of
q_next.
3. Output Logic: Assigns q = q_reg.
• Update sensitivity list to include all variables

(always @(*)).
Testbench Details:
• 5-bit counter tested (range: 0–31).
• Simulates various scenarios:
o Counting up when enable = 1, up = 1.

o Pausing the counter by disabling enable.

o Counting down after re-enabling with up =

0.
oLoading a specific value mid-count using
load = 1, d = value.
o Verified correct behavior at next positive

clock edge after load.

• Simulation Observations:
o After asserting load with d = 9, counter jumps from current value to 9.

o Continues counting in the current direction from loaded value.

o Correct load behavior confirmed by waveform at clock edges.

o Double assertion of load keeps counter at loaded value until de-asserted.

• Multiplexing Logic:
o The case statement for q_next acts like a 4-to-1 multiplexer.

o Based on two control signals: load and up.

• Load with 9 While Counting Down:
o Counter was counting down (up = 0).

o load = 1, d = 9 asserted.

o On next positive edge of the clock, counter loaded 9, overriding the decrement.

o Counter resumed counting down from 9 → 8 → 7 → 6 → 5 → 4.

o This caused a jump from 13 to 9, demonstrating parallel load behavior.

• Load with 7:

o At a later clock cycle, load = 1, d = 7.

o On the next clock edge, the counter loaded 7.

o Continued counting down from 7 → 6 → 5 → 4 → 3 → 2.

• Load with 11 While Counting Up:

o Changed direction to counting up (up = 1).

o load = 1, d = 11.

o On clock edge, counter loaded 11, then started counting up.

o Values observed: 11 → 12 → 13 → 14 → 15...

• Double Load Observation (Why 11 was held longer):

o Two consecutive clock cycles had load = 1, d = 11.

o So 11 was held for two clock periods before counting resumed.

o Actual counting resumed after load was de-asserted.

o Demonstrates that as long as load = 1, the counter holds d.

• Key Takeaways from Simulation:

o Counter loads value d on the rising edge of the clock if load = 1.

o Continues in the current direction (up/down) from the loaded value.

o Holding load = 1 keeps counter fixed at d, delaying counting.

o De-asserting load resumes normal counting based on up.