Convert DFF to 1-bit binary counter - Help Please

[Daku]

Could some Verilog guru please help ? I have the following working D
flip-flop.
I would like to convert it to a 1 bit counter, where the Q_bar output
is fed back
into the D input - I am not sure what modifications to apply.

`timescale 1ns/1ns

module dff( d, clk, reset, q, q_bar);
input d;
input clk;
input reset;
output q;
output q_bar;

reg q;
reg q_bar;
reg reset;

always @ (posedge clk or negedge reset)
if(~reset)
begin
q <= 1'b0;
end
else
begin
q <= d;
q_bar <= !d;
end
endmodule

Thanks in advance for your help.

 

[Jonathan Bromley]

On Fri, 3 Sep 2010 22:04:02 -0700 (PDT), Daku wrote:

Could some Verilog guru please help ? I have the following working D
flip-flop.
I would like to convert it to a 1 bit counter, where the Q_bar output
is fed back
into the D input - I am not sure what modifications to apply.

What an odd question - you've just told us exactly
what you need to do. So what are you stuck with?
It certainly doesn't need a "Verilog guru".

Before we get to some answers, let's critique your
existing code:
- Why is the reset called "reset" when in fact it's
active-low? Name it "reset_bar" or somesuch so that
its polarity is obvious to the user of your block.
Establish naming conventions for active-low ports,
and stick to your conventions.
- In SystemVerilog your code is OK, but in standard
Verilog the line "reg reset;" is a bug; a module's
input ports must be wires, not reg, inside a module.
Your code won't compile unless SystemVerilog
compilation is enabled in your tools.

The part I'm not sure about is "convert it to". Do you
intend to use your existing DFF as part of a new module
that implements a 1-bit counter? Or do you plan to
modify the original module?

In any sane world you would do neither of those things.
For RTL coding, a single DFF is far too small a block
to make sense as a module; that level of granularity
effectively takes you back to designing with schematics.
Instead, incorporate the one or two lines of "one bit
counter" functionality into the bigger always-block
that needs it. There are, of course, exceptions to
this: if you're trying to create simulation models
of the primitive cells in a library, for example,
or (dare I say it) if you're doing an assignment
for an unimaginative course tutor.

To build your 1-bit counter by composition, using
the DFF as a building block: you gave the answer
already! By the way, a 1-bit counter is commonly
called a "toggle flip-flop".

module toggleFF (enable, clk, reset, q, q_bar);
input enable;
input clk;
input reset;
output q;
output q_bar;

wire D; // input to the DFF

// instance of the DFF
dff dff_instance(D, clk, reset, q, q_bar);

// tweak the DFF's D input appropriately so that
// * the FF toggles if enable is true
// * the FF holds its value if enable is false
assign D = enable? q_bar : q;

endmodule

phew, that was hard ;-) This kind of stuff is done
all the time in hardware design: take an existing
function that is nearly what you want, and add a wrapper
that conditions its inputs and outputs to match the
protocols and behaviours you need. However, no
sensible RTL designer would do such a thing at this
very low level of abstraction, when it's so easy to
write the code inline in the place you need it...
if (enable)
q <= ~q;

Next question: where's your testbench?
--
Jonathan Bromley

 

[Cary R.]

Jonathan Bromley wrote:

Next question: where's your testbench?

Actually the next (maybe first) question should be is the missing reset
of q_bar what's tripping up the OP. If q_bar starts undefined and is
connected to the D then the FF will always return 1'bx. Of course a good
description of what was going wrong from the OP would have helped know
what to look for.

I also prefer to see ~ used to negate a value vs !. For this case they
both work exactly the same, but for a vectorized FF you'll get
dramatically different results. I think it's best to get into the habit
of using the correct operator to avoid problems down the road.

Cary

 

[Jonathan Bromley]

On Sat, 04 Sep 2010 08:47:28 -0700, "Cary R." wrote:

Actually the next (maybe first) question should be
is the missing reset of q_bar what's tripping up the OP.

Whoops, I missed that - well spotted!
--
Jonathan Bromley

 

[Daku]

Thanks for all your responses. I agree that at this level
of abstraction, it is better to work with schematics (SPICE).
I had started on that path, but could not get the 1-bit
counter to work, even at low frequencies. My ultimate design
goal is to make my design work at high frequencies (>= 40GHz)
So I wanted to test my design in Verilog, to check if there
is inherently wrong with my understanding.

On Sep 4, 1:12 pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

On Fri, 3 Sep 2010 22:04:02 -0700 (PDT), Daku wrote:
Could some Verilog guru please help ? I have the following working D
flip-flop.
I would like to convert it to a 1 bit counter, where the Q_bar output
is fed back
into the D input - I am not sure what modifications to apply.

What an odd question - you've just told us exactly
what you need to do. So what are you stuck with?
It certainly doesn't need a "Verilog guru".

Before we get to some answers, let's critique your
existing code:
- Why is the reset called "reset" when in fact it's
active-low? Name it "reset_bar" or somesuch so that
its polarity is obvious to the user of your block.
Establish naming conventions for active-low ports,
and stick to your conventions.
- In SystemVerilog your code is OK, but in standard
Verilog the line "reg reset;" is a bug; a module's
input ports must be wires, not reg, inside a module.
Your code won't compile unless SystemVerilog
compilation is enabled in your tools.

The part I'm not sure about is "convert it to". Do you
intend to use your existing DFF as part of a new module
that implements a 1-bit counter? Or do you plan to
modify the original module?

In any sane world you would do neither of those things.
For RTL coding, a single DFF is far too small a block
to make sense as a module; that level of granularity
effectively takes you back to designing with schematics.
Instead, incorporate the one or two lines of "one bit
counter" functionality into the bigger always-block
that needs it. There are, of course, exceptions to
this: if you're trying to create simulation models
of the primitive cells in a library, for example,
or (dare I say it) if you're doing an assignment
for an unimaginative course tutor.

To build your 1-bit counter by composition, using
the DFF as a building block: you gave the answer
already! By the way, a 1-bit counter is commonly
called a "toggle flip-flop".

module toggleFF (enable, clk, reset, q, q_bar);
input enable;
input clk;
input reset;
output q;
output q_bar;

wire D; // input to the DFF

// instance of the DFF
dff dff_instance(D, clk, reset, q, q_bar);

// tweak the DFF's D input appropriately so that
// * the FF toggles if enable is true
// * the FF holds its value if enable is false
assign D = enable? q_bar : q;

endmodule

phew, that was hard ;-) This kind of stuff is done
all the time in hardware design: take an existing
function that is nearly what you want, and add a wrapper
that conditions its inputs and outputs to match the
protocols and behaviours you need. However, no
sensible RTL designer would do such a thing at this
very low level of abstraction, when it's so easy to
write the code inline in the place you need it...
if (enable)
q <= ~q;

Next question: where's your testbench?
--
Jonathan Bromley