KJ
Guest
Sat Jun 12, 2010 5:27 am
On Jun 9, 12:49 pm, Rob Gaddi <rga...@technologyhighland.com> wrote:
Quote:
On 6/8/2010 6:12 PM, KJ wrote:
Depending on what you're doing with the frequency measurements, an
LFSR counter would work much faster than a ripple counter...you lose
the binary number interpretation of the bits of the counter though.
KJ
Would you implement your LFSR counter as a shift register with the input
signal driving all of the flops independently? The skew there's going
to be fatal;
I have never found it to be fatal. A hypothetical 32 bit counter
running at 1 GHz can time things up to 4.2 seconds with 1 ps
resolution...now maybe if I had a need for a 786 bit LFSR like whygee
posted (*1) the loading could get to be an issue, but since 1 GHz and
4.2 seconds at 1 ps accuracy are beyond where I've had a need, loading
hasn't been a problem.
That 786 bit counter though would allow me to measure 1.28E220 years
to a ps (if I did the math right). But I'm betting the device would
have long since have returned to silicon, copper and other elements
long before that.
Quote:
all you need is one setup time violation one time and
everything goes to hell.
That's always the case...not unique to any form of counter
Quote:
With the ripple counter, I'll say again, you can reliably measure up to
the single flop toggle frequency. What you're saying about having to
wait for the system to settle is a different issue. The counter itself
can be clocked substantially faster than the overall system settling
time because you don't have to wait for the entire ripple to go through
in order to count; only to read/clear. That happens on a different
timescale than the frequency counting itself does.
You're making an assumption about the timescales for counting and
reading always being different. Whether they are or not depends on
the application. For those cases where that assumption applies,
you're correct that a ripple counter might be the best candidate for
the implementation...also assuming you're in a device that supports
multiple clocks in the first place (flashing back to simple PLD
devices, 16V8, things like that...only as a reminder that the
implementation technology might be a limitation as well)
Kevin Jennings
(*1)
http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/697d8a6d0769652b?hl=en#
