[Q] : async event counter

D

dong seok huh

I made a 16bit up/down counter.
input source is a event source, and couter count-up at riging edge of input
source.
but If the counter count-up at the same time when I read the counter value.
wrong data may be read , when the count value change from 000F to 0010.
16bit data are changed with some skew.
How can I make the perfect counter ?
I heared somebody use two counter register.....
 
R

Ralf Hildebrandt

dong said:
I made a 16bit up/down counter.
input source is a event source, and couter count-up at riging edge of input
source.
but If the counter count-up at the same time when I read the counter value.
wrong data may be read , when the count value change from 000F to 0010.
16bit data are changed with some skew.

This is quite normal...
How can I make the perfect counter ?

Well.. the perfect counter is a theoretical counter. ;-)

Ask yourself: Why do you want to read during the count-event?

If it is nessecary, you may read the counter several times. Then you can
do e.g. a majority vote.

Ralf
 
A

Andy Peters

dong seok huh said:
I made a 16bit up/down counter.
input source is a event source, and couter count-up at riging edge of input
source.
but If the counter count-up at the same time when I read the counter value.
wrong data may be read , when the count value change from 000F to 0010.
16bit data are changed with some skew.
How can I make the perfect counter ?
I heared somebody use two counter register.....

Read the counter synchronously.

-a
 
M

Mike Treseler

dong said:
but If the counter count-up at the same time when I read the counter value.
wrong data may be read , when the count value change from 000F to 0010.
16bit data are changed with some skew.
How can I make the perfect counter ?
I heared somebody use two counter register.....

Yes, I would use two registers,
one counts and resets to 0 at the synchronous read strobe.
The second register holds the value between read strobes.
Be sure to cover the "count during strobe" case.

-- Mike Treseler
 
C

Charles M. Elias

dong seok huh said:
I made a 16bit up/down counter.
input source is a event source, and couter count-up at riging edge of input
source.
but If the counter count-up at the same time when I read the counter value.
wrong data may be read , when the count value change from 000F to 0010.
16bit data are changed with some skew.
How can I make the perfect counter ?
I heared somebody use two counter register.....

You could make a register having the same width as the counter. Use
the same strobe that increments the counter to clock the counter
contents into the register. You will always be behind by one event
count. This method works because the counter and the register use the
same clock edge to count and load, respectively. The register loads
the current count before the counter actually increments (this assumes
comparable speeds for both the counter and the register). This
general technique is used in synchronous logic all the time. If this
method bothers you, and if you have a wide enough strobe (wide enough
to allow the counter to settle to its new count) you can invert the
strobe to the register so that it loads on the strobe trailing edge.

Charles
 
D

dong seok huh

Thank you for your answer.
but I have one question.
How can I read the register during the register value changing ?
I think It is same problem. or My mis-understanding....
Please advise one more time....
 
R

Renaud Pacalet

dong seok huh a écrit :
Thank you for your answer.
but I have one question.
How can I read the register during the register value changing ?
I think It is same problem. or My mis-understanding....

I suspect your understanding problem is about synchronous systems, not
about VHDL. When you write "read the register" what do you exactly mean?
Almost instantaneously sample it's value in another register? Then you
need to understand that synchronous systems are made in order to solve
this. It's not a feature it's *the* feature. And it's implemented with a
special device: the D flip-flop or DFF. This device has 2 inputs: clock
(CLK) and data input (D) and one output: data output (Q). It samples its
input D at every rising edge of its clock CLK. After a propagation time
(Tp) it drives its output Q with the new sampled data value. Between
rising edges of its clock, value changes on D have no effect on the DFF;
the DFF "stores" the sampled value. But as it's a physical and not an
ideal device it cannot sample its input instantaneously. This sampling
action takes a few picoseconds. During this short period of time -
defined by a "setup" time (Ts) before and a "hold" time (Th) after the
rising edge - the data input must stay stable. If it doesn't the
sampling can give unpredictable results (the picture can be blurred).

In a synchronous system combinational computing parts are surrounded by
registers made of DFFs. The input registers hold the input data stable
during the computation and the output registers sample the result once
it's computed so that it's held stable and may be used by others parts
of the system. Input registers and output registers sample at the same
time; they share the same clock. If the clock period duration is at
least the combinational computing time plus the DFF propagation time
plus the DFF setup time then everything is fine and every computation is
finished when comes the sampling time with the needed small margin in
order to avoid a blurred picture.

An extreme case is when the combinational computing part is only wires
(identity) and computes nothing at all. This is the case in shift
registers, for instance. In such cases the computing time is zero
picosecond (it's not so simple, you know, because it takes some time to
propagate signals from on end of a wire to the other, but let's
simplify). So what happens when the output of a DFF is directely
connected to the input of another with no computing part in between? One
could expect some problem at the rising edge of clock because both DFFs
will sample their inputs and the input of the second is the output of
the first... Well, if the clock of both DFFs is exactly the same, with
no skew, then there is no problem at all because the propagation time of
a DFF (Tp) is always larger than its hold time (Th). Draw a simple
chronogram of all this and you'll understand.

Warning # 1: this is only a very simplified vue; if some of the above
was new to you you should consider reading a book.

Warning # 2: the way this is modeled in VHDL (or Verilog, or SystemC) is
another question that needs a lot of explanations too. And reading a
book is a good solution.

Hope it helps.

Best regards,
--
Renaud Pacalet, GET/ENST/COMELEC/LabSoC
Institut Eurecom BP 193, 2229 route des Cretes
F-06904 Sophia-Antipolis Cedex
Tel : +33 (0) 4 9300 2770
Fax : +33 (0) 4 9300 2627
Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,020
Latest member
GenesisGai

Latest Threads

Top