Question about registered outputs.

P

pallav

Guest
I'm reading one of Cliff Cummings paper on using registered outputs to
get clean, glitch-free outputs (goal is to eventually implement a
synchronous FIFO). A question I have is, are registered outputs only
relevant for Mealy machines? I'm experimenting with a synchronous up/
down counter (Moore machine). I have two implementations:
sync_updown_counter is following the style presented in the paper. The
other implementation, sync_updown_counter1, is the typical way.

sync_updown_counter: http://www.pastey.net/122017

sync_updown_counter1: http://www.pastey.net/122018

I synthesized both designs using Synopsys Compiler with "compile -
exact_map". The exact map flags makes it strictly match the DFF in
HDL. The structure of sync_updown_counter is very clear. The "cloud"
combinational logic is on the left and goes into the flip flops. The
structure of the sync_updown_counter1 is not that organized. However,
the area of sync_updown_counter1 is less than sync_updown_counter by
about 60 units although they both use 4 flip-flops.

However, since the counter next state is only dependent on its current
state (i.e., a Moore machine), I don't think there will be a glitch
issue. Thus, is there a reason to use registered outputs for counters
or Moore machines in general?

Thanks for any insight.

Kind regards,
 
On Wed, 19 Aug 2009 12:17:59 -0700 (PDT)
pallav <pallavgupta@gmail.com> wrote:

I'm reading one of Cliff Cummings paper on using registered outputs to
get clean, glitch-free outputs (goal is to eventually implement a
synchronous FIFO). A question I have is, are registered outputs only
relevant for Mealy machines? I'm experimenting with a synchronous up/
down counter (Moore machine). I have two implementations:
sync_updown_counter is following the style presented in the paper. The
other implementation, sync_updown_counter1, is the typical way.

sync_updown_counter: http://www.pastey.net/122017
Click to expand...
A side note on the combinatorial logic count_next. I assume that the
last else statement is meant to be paired with the last if statement
(although bracketing them with begin/end would be ideal). If so, the
always block will generate a latch for count_next, which may not be
your true intention. I would code it the following way:

always @(/*AUTOSENSE*/count or en or in or loadb or up)
if (!loadb)
count_next = in;
else if (en)
count_next = count + {{WIDTH-1{~up}}, 1'b1};
else
count_next = count;

or to be less reader-friendly:

always @(/*AUTOSENSE*/count or en or in or loadb or up)
if (!loadb)
count_next = in;
else
count_next = count + {{WIDTH-1{~up & en}}, en};

~Zheng
 
On Aug 19, 3:17 pm, pallav <pallavgu...@gmail.com> wrote:
I'm reading one of Cliff Cummings paper on using registered outputs to
get clean, glitch-free outputs (goal is to eventually implement a
synchronous FIFO). A question I have is, are registered outputs only
relevant for Mealy machines? I'm experimenting with a synchronous up/
down counter (Moore machine). I have two implementations:
sync_updown_counter is following the style presented in the paper. The
other implementation, sync_updown_counter1, is the typical way.

sync_updown_counter:http://www.pastey.net/122017

sync_updown_counter1:http://www.pastey.net/122018

I synthesized both designs using Synopsys Compiler with "compile -
exact_map". The exact map flags makes it strictly match the DFF in
HDL. The structure of sync_updown_counter is very clear. The "cloud"
combinational logic is on the left and goes into the flip flops. The
structure of the sync_updown_counter1 is not that organized. However,
the area of sync_updown_counter1 is less than sync_updown_counter by
about 60 units although they both use 4 flip-flops.

However, since the counter next state is only dependent on its current
state  (i.e., a Moore machine), I don't think there will be a glitch
issue. Thus, is there a reason to use registered outputs for counters
or Moore machines in general?

Thanks for any insight.

Kind regards,
Click to expand...
Assuming your dff_sync_r has a synchronous reset, I don't
see any difference in the two modules other than naming the
nets on the D side of the flops. The flop outputs should
still be the module outputs, and as you said there should be
no glitch. There certainly will be glitches on count_next
and the equivalent unnamed nets in the other module.

I think Cummings was concerned about using the combinatorial
nets like count_next where you can't tolerate glitches,
such as the Gray counter in a dual-clocked FIFO. If you
have a binary counter, it is easy to convert it to Gray
code with a bunch of XOR gates. But you need to re-
register the output of those XOR gates with the same clock
or you'll have glitches that might be caught in the other
clock domain.

Regards,
Gabor
 
Hi Gabor/Jason,

Thanks for your insight again and pointing out the silly mistake. I
think I understand the idea of registered outputs better now.

Kind regards.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top