Implementing a very fast counterin VirtexII

[Erez Birenzwig]

Hi,

I'm trying to write some code for a 64 bit counter for a VirtexII.

The problem I'm facing is that it has to run at least at 200MHz, and
therefore
a simple "a = a + 1" doesn't work (Xilinx rate the 64b counter to 114MHz).

I've tried a split approach with four smaller counters and a selector
depending on the carry out of the previous stages but it only got me to
about
180MHz.

Did anyone ever had a similar problem and solved it ?
Unfortunately I'm not familiar with a pipelined implementation, I'll be
happy
to learn one.

Many thanks,
Erez.

 

[Peter Alfke]

"Counter" can mean many things.
If you need a synchronous counter that gives you the updated value
before the next count pulse comes in, that is a demanding design and may
have timing problems at 200 MHz.

If, at the other extreme, you just need a counter that can resolve 200 (
or 500+ ) MHz, and you can wait some nanoseconds before you read the
final count value, that is trivial. In the extreme case you would just
concatenate 2-bit Johnson counters (at least at the input end), one
slice clocking the next. And there are many variations on this theme.
I built a 400 MHz frequency counter 5 years ago with XC4002XL...Playing
around, aiming at 1 GHz now.

Peter Alfke, Xilinx Applications


Erez Birenzwig wrote:

Hi,

I'm trying to write some code for a 64 bit counter for a VirtexII.

The problem I'm facing is that it has to run at least at 200MHz, and
therefore
a simple "a = a + 1" doesn't work (Xilinx rate the 64b counter to 114MHz).

I've tried a split approach with four smaller counters and a selector
depending on the carry out of the previous stages but it only got me to
about
180MHz.

Did anyone ever had a similar problem and solved it ?
Unfortunately I'm not familiar with a pipelined implementation, I'll be
happy
to learn one.

Many thanks,
Erez.

 

[Erez Birenzwig]

To be more precise the implementation requires the calculation of:
a = a + 1

When a is a 64bit vector, every clock cycle at 200MHz, using a virtexII-6
FPGA.

Erez.


"Peter Alfke" <peter@xilinx.com> wrote in message
news:3FB01875.A2C23F2F@xilinx.com...

"Counter" can mean many things.
If you need a synchronous counter that gives you the updated value
before the next count pulse comes in, that is a demanding design and may
have timing problems at 200 MHz.

If, at the other extreme, you just need a counter that can resolve 200 (
or 500+ ) MHz, and you can wait some nanoseconds before you read the
final count value, that is trivial. In the extreme case you would just
concatenate 2-bit Johnson counters (at least at the input end), one
slice clocking the next. And there are many variations on this theme.
I built a 400 MHz frequency counter 5 years ago with XC4002XL...Playing
around, aiming at 1 GHz now.

Peter Alfke, Xilinx Applications


Erez Birenzwig wrote:

Hi,

I'm trying to write some code for a 64 bit counter for a VirtexII.

The problem I'm facing is that it has to run at least at 200MHz, and
therefore
a simple "a = a + 1" doesn't work (Xilinx rate the 64b counter to
114MHz).

I've tried a split approach with four smaller counters and a selector
depending on the carry out of the previous stages but it only got me to
about
180MHz.

Did anyone ever had a similar problem and solved it ?
Unfortunately I'm not familiar with a pipelined implementation, I'll
be
happy
to learn one.

Many thanks,
Erez.

 

[Peter Alfke]

I would suggest detecting FFFF and generating a wait state or two when
you reach that value. The probability is one in 64K, so it should hardly
have any impact on performance.

Peter Alfke
==================
Erez Birenzwig wrote:

To be more precise the implementation requires the calculation of:
a = a + 1

When a is a 64bit vector, every clock cycle at 200MHz, using a virtexII-6
FPGA.

Erez.

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3FB01875.A2C23F2F@xilinx.com...
"Counter" can mean many things.
If you need a synchronous counter that gives you the updated value
before the next count pulse comes in, that is a demanding design and may
have timing problems at 200 MHz.

If, at the other extreme, you just need a counter that can resolve 200 (
or 500+ ) MHz, and you can wait some nanoseconds before you read the
final count value, that is trivial. In the extreme case you would just
concatenate 2-bit Johnson counters (at least at the input end), one
slice clocking the next. And there are many variations on this theme.
I built a 400 MHz frequency counter 5 years ago with XC4002XL...Playing
around, aiming at 1 GHz now.

Peter Alfke, Xilinx Applications


Erez Birenzwig wrote:

Hi,

I'm trying to write some code for a 64 bit counter for a VirtexII.

The problem I'm facing is that it has to run at least at 200MHz, and
therefore
a simple "a = a + 1" doesn't work (Xilinx rate the 64b counter to
114MHz).

I've tried a split approach with four smaller counters and a selector
depending on the carry out of the previous stages but it only got me to
about
180MHz.

Did anyone ever had a similar problem and solved it ?
Unfortunately I'm not familiar with a pipelined implementation, I'll
be
happy
to learn one.

Many thanks,
Erez.

 

[Erez Birenzwig]

Then when you read the counter every clock cycle once every 64K counts
you'll
get a wrong result. I don't think it's good enough.. Remember the FMUL bug ?

Anyway I got a good answer from another list :

1) Build a fast 2-bit counter
2) Build a slow 62-bit counter, with enable
3) Use enable = q[1]&q[0]
4) latch the slow counter using the enable as well

You get a full 4 cycles for the carry to ripple through the upper 62
bits. Be careful in timing analysis. Some systems let you specify that
the carry chain is a multi-cycle path. Other's force you to ignore
these paths with falsepath commands.

(Thanks Bill for the help).

Erez.


"Peter Alfke" <peter@xilinx.com> wrote in message
news:3FB0230F.3FC83434@xilinx.com...

I would suggest detecting FFFF and generating a wait state or two when
you reach that value. The probability is one in 64K, so it should hardly
have any impact on performance.

Peter Alfke
==================
Erez Birenzwig wrote:

To be more precise the implementation requires the calculation of:
a = a + 1

When a is a 64bit vector, every clock cycle at 200MHz, using a
virtexII-6
FPGA.

Erez.

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3FB01875.A2C23F2F@xilinx.com...
"Counter" can mean many things.
If you need a synchronous counter that gives you the updated value
before the next count pulse comes in, that is a demanding design and
may
have timing problems at 200 MHz.

If, at the other extreme, you just need a counter that can resolve 200
(
or 500+ ) MHz, and you can wait some nanoseconds before you read the
final count value, that is trivial. In the extreme case you would just
concatenate 2-bit Johnson counters (at least at the input end), one
slice clocking the next. And there are many variations on this theme.
I built a 400 MHz frequency counter 5 years ago with
XC4002XL...Playing
around, aiming at 1 GHz now.

Peter Alfke, Xilinx Applications


Erez Birenzwig wrote:

Hi,

I'm trying to write some code for a 64 bit counter for a VirtexII.

The problem I'm facing is that it has to run at least at 200MHz,
and
therefore
a simple "a = a + 1" doesn't work (Xilinx rate the 64b counter to
114MHz).

I've tried a split approach with four smaller counters and a
selector
depending on the carry out of the previous stages but it only got me
to
about
180MHz.

Did anyone ever had a similar problem and solved it ?
Unfortunately I'm not familiar with a pipelined implementation,
I'll
be
happy
to learn one.

Many thanks,
Erez.

 

[fe]

"Erez Birenzwig" <erez_birenzwig@hotmail.com> wrote in message
news:9eUrb.2$%o4.221@news.xtra.co.nz...

Hi,

I'm trying to write some code for a 64 bit counter for a VirtexII.

The problem I'm facing is that it has to run at least at 200MHz, and
therefore
a simple "a = a + 1" doesn't work (Xilinx rate the 64b counter to 114MHz).

I've tried a split approach with four smaller counters and a selector
depending on the carry out of the previous stages but it only got me to
about
180MHz.

Did anyone ever had a similar problem and solved it ?
Unfortunately I'm not familiar with a pipelined implementation, I'll be
happy
to learn one.

example 64bit pipelined counter with two 32bit counter.
(Please view in fixed-width font, e.g. Courier)
-- (+) : adder (count)
-- [ ] : dff
--
-- +-----------+
-- | |
-- 1--(+)-+-[31:0]-+---------[31:0]-----+
-- | |
-- +-[carry]-+ |
-- | |
-- | +------------+ |
-- | | | |
-- +-(+)---[63:32]-+---+---cnt(63:0)

ps_cnt_pipeline : process(i_rst_an, i_clk) is
constant C_CNT_WIDTH2 : positive := G_CNT_WIDTH / 2;
variable v_cnt1_d : unsigned(C_CNT_WIDTH2 downto 0);
variable v_cnt1_q1 : unsigned(C_CNT_WIDTH2-1 downto 0);
variable v_cnt1_q2 : unsigned(C_CNT_WIDTH2-1 downto 0);
variable v_carry_q1 : unsigned(0 downto 0);
variable v_cnt2_q2 : unsigned(G_CNT_WIDTH-C_CNT_WIDTH2-1 downto 0);
begin
if i_rst_an = '0' then
v_carry_q1 := (others => '0');
v_cnt1_q1 := (others => '0');
v_cnt1_q2 := (others => '0');
v_cnt2_q2 := (others => '0');
elsif rising_edge(i_clk) then
v_cnt1_d := ('0' & v_cnt1_q1) + 1;
v_cnt1_q2 := v_cnt1_q1;
v_cnt2_q2 := v_cnt2_q2 + v_carry_q1;
v_carry_q1(0) := v_cnt1_d(C_CNT_WIDTH2);
v_cnt1_q1 := v_cnt1_d(C_CNT_WIDTH2-1 downto 0);
end if;
o_cnt_q <= std_logic_vector(v_cnt2_q2 & v_cnt1_q2);
end process;

regards,
fe

Many thanks,
Erez.

 

[Goran Bilski]

How do you use the counter?
Do you read current counter values or are you only interested when it
reached zero?

Göran

Erez Birenzwig wrote:

Hi,

I'm trying to write some code for a 64 bit counter for a VirtexII.

The problem I'm facing is that it has to run at least at 200MHz, and
therefore
a simple "a = a + 1" doesn't work (Xilinx rate the 64b counter to 114MHz).

I've tried a split approach with four smaller counters and a selector
depending on the carry out of the previous stages but it only got me to
about
180MHz.

Did anyone ever had a similar problem and solved it ?
Unfortunately I'm not familiar with a pipelined implementation, I'll be
happy
to learn one.

Many thanks,
Erez.

 

[Uwe Bonnes]

Erez Birenzwig <erez_birenzwig@hotmail.com> wrote:

:> > > >
:> > > > Many thanks,
:> > > > Erez.

Argh.

Why do so many people fullquote? Is it so hard to delete non-needed parts of
the posting they refer to?

Fullquoting spoils the archives and make them harder to use. So people don't
search the archive but instead ask the same questions all over. That makes
the newsgroup hard to use.

Bye

--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

 

[John_H]

Every clock cycle? Not gated/enabled or cleared?

You split the counter into halves earlier, correct? Pre-decode the terminal
count from the fast counter so you have a synchronous TC signal when the
32'hffff_ffff arrives (or 8'hff or whatever size you choose). With the
synchronous TC fed to the enable of the top, slow counter you can achieve
great speeds.

Only a little more coordination is needed for proper enables, clears, or
loads, but the design should be easy to achieve once you understand the
"tricks" that will help you "retime" your synchronous designs.


"Erez Birenzwig" <erez_birenzwig@hotmail.com> wrote in message
news:W0Vrb.67$%o4.12245@news.xtra.co.nz...

To be more precise the implementation requires the calculation of:
a = a + 1

When a is a 64bit vector, every clock cycle at 200MHz, using a virtexII-6
FPGA.

Erez.

 

[Peter Alfke]

Erez
This is a good idea for a counter, but it does not work for a general
purpose incrementer where you would throw new vectors at it on every
clock cycle. In that case, my suggestion of detecting FFFF and
generating a wait state works well. (I hope you did not think I was just
brushing the problem under the carpet. I solve it with the additional
wait state ).
Regarding your 2-stage prescaler, I would extend this to three stages.
It gives you double the timing benefit, and it fits the 4-input LUT
structure very nicely.
I don't understand your item 4, but that may be just semantics.

Good luck, and happy counting at 400+MHz!
Peter Alfke, Xilinx Applications
=========================
Erez Birenzwig wrote:

Then when you read the counter every clock cycle once every 64K counts
you'll
get a wrong result. I don't think it's good enough.. Remember the FMUL bug ?

Anyway I got a good answer from another list :

1) Build a fast 2-bit counter
2) Build a slow 62-bit counter, with enable
3) Use enable = q[1]&q[0]
4) latch the slow counter using the enable as well

You get a full 4 cycles for the carry to ripple through the upper 62
bits. Be careful in timing analysis. Some systems let you specify that
the carry chain is a multi-cycle path. Other's force you to ignore
these paths with falsepath commands.

(Thanks Bill for the help).

Erez.

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3FB0230F.3FC83434@xilinx.com...
I would suggest detecting FFFF and generating a wait state or two when
you reach that value. The probability is one in 64K, so it should hardly
have any impact on performance.

Peter Alfke
==================
Erez Birenzwig wrote:

To be more precise the implementation requires the calculation of:
a = a + 1

When a is a 64bit vector, every clock cycle at 200MHz, using a
virtexII-6
FPGA.

Erez.

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3FB01875.A2C23F2F@xilinx.com...
"Counter" can mean many things.
If you need a synchronous counter that gives you the updated value
before the next count pulse comes in, that is a demanding design and
may
have timing problems at 200 MHz.

If, at the other extreme, you just need a counter that can resolve 200
(
or 500+ ) MHz, and you can wait some nanoseconds before you read the
final count value, that is trivial. In the extreme case you would just
concatenate 2-bit Johnson counters (at least at the input end), one
slice clocking the next. And there are many variations on this theme.
I built a 400 MHz frequency counter 5 years ago with
XC4002XL...Playing
around, aiming at 1 GHz now.

Peter Alfke, Xilinx Applications


Erez Birenzwig wrote:

Hi,

I'm trying to write some code for a 64 bit counter for a VirtexII.

The problem I'm facing is that it has to run at least at 200MHz,
and
therefore
a simple "a = a + 1" doesn't work (Xilinx rate the 64b counter to
114MHz).

I've tried a split approach with four smaller counters and a
selector
depending on the carry out of the previous stages but it only got me
to
about
180MHz.

Did anyone ever had a similar problem and solved it ?
Unfortunately I'm not familiar with a pipelined implementation,
I'll
be
happy
to learn one.

Many thanks,
Erez.

 

[Jim Granville]

Erez Birenzwig wrote:

Then when you read the counter every clock cycle once every 64K counts
you'll
get a wrong result. I don't think it's good enough.. Remember the FMUL bug ?

Anyway I got a good answer from another list :

1) Build a fast 2-bit counter
2) Build a slow 62-bit counter, with enable
3) Use enable = q[1]&q[0]
4) latch the slow counter using the enable as well

You get a full 4 cycles for the carry to ripple through the upper 62
bits. Be careful in timing analysis. Some systems let you specify that
the carry chain is a multi-cycle path. Other's force you to ignore
these paths with falsepath commands.
Peter Alfke wrote:

Erez
This is a good idea for a counter, but it does not work for a general
purpose incrementer where you would throw new vectors at it on every
clock cycle. In that case, my suggestion of detecting FFFF and
generating a wait state works well. (I hope you did not think I was just
brushing the problem under the carpet. I solve it with the additional
wait state ).
Regarding your 2-stage prescaler, I would extend this to three stages.
It gives you double the timing benefit, and it fits the 4-input LUT
structure very nicely.
I don't understand your item 4, but that may be just semantics.

I think item 4) was to cover capture of the counter at any
instant, and to cover the carry ripple.
I'm with Peter in questioning 4).
Carry ripple is certainly long, but this is on the .D side, and
determines the NEXT Clock delay. However any Capture is on the .Q side,
and all Q's will be fully sync (no ripple adders )
Capture of both the prescaler, and long counter, can be clock
syncronous, and does not need any enables.

Capture and Clear (can be more application usefull), can
be done in a single clock with a little more .D side logic.

Capture of fractional clocks, to push the time resolve better than
1/clock speed, is challenging, but looks possible in modern FPGA.

-jg

 

[Erez Birenzwig]

"Jim Granville" <jim.granville@designtools.co.nz> wrote in message
news:3FB1470C.F22@designtools.co.nz...

I think item 4) was to cover capture of the counter at any
instant, and to cover the carry ripple.
I'm with Peter in questioning 4).
Carry ripple is certainly long, but this is on the .D side, and
determines the NEXT Clock delay. However any Capture is on the .Q side,
and all Q's will be fully sync (no ripple adders )
Capture of both the prescaler, and long counter, can be clock
syncronous, and does not need any enables.

4) is to cover the fact that once you enable the +1 on the long carry chain
you can't
sample it at the next clock cycle (It won't be ready by then), so you have
to latch the
previous value which is the new count value.

The problem is that I must be able to sample the counter on every arbitary
clock cycle
therefore it must be glitch free.

The counter that I need doesn't require a clear but thanks for the thought,
it needs a load though.

Capture and Clear (can be more application usefull), can
be done in a single clock with a little more .D side logic.

Capture of fractional clocks, to push the time resolve better than
1/clock speed, is challenging, but looks possible in modern FPGA.

-jg

 

[Jim Granville]

Erez Birenzwig wrote:

"Jim Granville" <jim.granville@designtools.co.nz> wrote in message
news:3FB1470C.F22@designtools.co.nz...
I think item 4) was to cover capture of the counter at any
instant, and to cover the carry ripple.
I'm with Peter in questioning 4).
Carry ripple is certainly long, but this is on the .D side, and
determines the NEXT Clock delay. However any Capture is on the .Q side,
and all Q's will be fully sync (no ripple adders )
Capture of both the prescaler, and long counter, can be clock
syncronous, and does not need any enables.

4) is to cover the fact that once you enable the +1 on the long carry chain
you can't sample it at the next clock cycle (It won't be ready by then), so you have
to latch the previous value which is the new count value.

We may be differing in topology
A +1 is normally done on the register INPUT side (.D), not on the
register OUTPUT (.Q) side.
On a FPGA, you use carry logic/ +1 maths, on a CPLD, you use
wide-AND and toggle flipflops.

So, it does not matter if the long carry chain results are not ready
(and you are right, it will not be ready ), because the
latch sample is taken from the .Q, whilst the carry results drive the .D
You DO need to enable the counter clock, as that requires a fully
settled
summation result.

-jg

 

[Peter Alfke]

Erez,
there are some misunderstandings here:
"Your" counter (with its 2- or 3- bit front end that decodes an enable
to the 62 more significant bits) looks and behaves like a perfectly
synchronous counter. The carry into the 62-bit section has been active
and rippling up the chain, but the non-enable input stopped any action,
until Enable goes active and the next clock edge causes the whole
counter to increment, synchronously.
You don't have to do anything to prevent the ripple carry chain to do
something stupid, the Enable signal takes care of that.
You can read the whole proper count value within a nanosecond after each
incoming clock.
So far, so good.
But, as I said, do not try to use this as a general purpose incrementer,
where an arbitrary vector might come in on any clock tick. It will fail
miserably, but I showed you the solution (using a wait state).

Peter Alfke, Xilinx Applications
=============================
Erez Birenzwig wrote:

"Jim Granville" <jim.granville@designtools.co.nz> wrote in message
news:3FB1470C.F22@designtools.co.nz...
I think item 4) was to cover capture of the counter at any
instant, and to cover the carry ripple.
I'm with Peter in questioning 4).
Carry ripple is certainly long, but this is on the .D side, and
determines the NEXT Clock delay. However any Capture is on the .Q side,
and all Q's will be fully sync (no ripple adders )
Capture of both the prescaler, and long counter, can be clock
syncronous, and does not need any enables.

4) is to cover the fact that once you enable the +1 on the long carry chain
you can't
sample it at the next clock cycle (It won't be ready by then), so you have
to latch the
previous value which is the new count value.

The problem is that I must be able to sample the counter on every arbitary
clock cycle
therefore it must be glitch free.

The counter that I need doesn't require a clear but thanks for the thought,
it needs a load though.


Capture and Clear (can be more application usefull), can
be done in a single clock with a little more .D side logic.

Capture of fractional clocks, to push the time resolve better than
1/clock speed, is challenging, but looks possible in modern FPGA.

-jg

 

[Erez Birenzwig]

"Jim Granville" <jim.granville@designtools.co.nz> wrote in message
news:3FB15093.48E7@designtools.co.nz...

Erez Birenzwig wrote:

"Jim Granville" <jim.granville@designtools.co.nz> wrote in message
news:3FB1470C.F22@designtools.co.nz...

4) is to cover the fact that once you enable the +1 on the long carry
chain
you can't sample it at the next clock cycle (It won't be ready by then),
so you have
to latch the previous value which is the new count value.

We may be differing in topology
A +1 is normally done on the register INPUT side (.D), not on the
register OUTPUT (.Q) side.
On a FPGA, you use carry logic/ +1 maths, on a CPLD, you use
wide-AND and toggle flipflops.

Sorry, you're right on the spot there. My mistake.

So, it does not matter if the long carry chain results are not ready
(and you are right, it will not be ready ), because the
latch sample is taken from the .Q, whilst the carry results drive the .D
You DO need to enable the counter clock, as that requires a fully
settled
summation result.

-jg

 

[Francisco Rodriguez]

"Erez Birenzwig" <erez_birenzwig@hotmail.com> escribió en el mensaje
news:x_bsb.1057$%o4.34282@news.xtra.co.nz...

"Jim Granville" <jim.granville@designtools.co.nz> wrote in message
news:3FB1470C.F22@designtools.co.nz...
I think item 4) was to cover capture of the counter at any
instant, and to cover the carry ripple.
I'm with Peter in questioning 4).
Carry ripple is certainly long, but this is on the .D side, and
determines the NEXT Clock delay. However any Capture is on the .Q side,
and all Q's will be fully sync (no ripple adders )
Capture of both the prescaler, and long counter, can be clock
syncronous, and does not need any enables.

4) is to cover the fact that once you enable the +1 on the long carry
chain
you can't
sample it at the next clock cycle (It won't be ready by then), so you have
to latch the
previous value which is the new count value.

The problem is that I must be able to sample the counter on every arbitary
clock cycle
therefore it must be glitch free.

It wouldn't be easier to always latch the low part?

That is, you build a circuit with a latency of 1 cycle to load a, and then
you have new a+1 result on every cycle.

Something like this:

process (...)
begin
if rising_edge(clk) then
a_low <= a_low + 1;
if (a_low = x"FFFF") then
enable_high <= '1';
else
enable_high <= '0';
end if;
if (enable_high = '1') then
a_high <= a_high + 1;
end if;
late_a_low <= a_low;
end if;
end process;

And the output is
a <= a_high & late_a_low;

Of course, additional logic is needed to load the counter with a predefined
value.

Once you get a (correct) value on a (by the load operation, not shown
above),
a_low maintains the low part of the _next_ count, while a_high has the high
part of the _current_ count.
That is why you need to delay a_low by a clock period.

I've tested a similar approach for a 64 bit counter running >200MHz on a
virtex2 -4 speed grade
although in my case the counter was built from 8 8-bit blocks.


Regards
Francisco

The counter that I need doesn't require a clear but thanks for the
thought,
it needs a load though.


Capture and Clear (can be more application usefull), can
be done in a single clock with a little more .D side logic.

Capture of fractional clocks, to push the time resolve better than
1/clock speed, is challenging, but looks possible in modern FPGA.

-jg

 

[Peter Alfke]

I hope it is understood by now that all these complicated suggestions
are unnecessary or counter-productive (pun intended).
The whole counter, including its front-end is (and behaves like) a
completely synchronous counter, with all outputs properly available
about a nanosecond after each count clock tick.
Let's keep simple things simple!
Peter Alfke, Xilinx
======================
Francisco Rodriguez wrote:

"Erez Birenzwig" <erez_birenzwig@hotmail.com> escribió en el mensaje
news:x_bsb.1057$%o4.34282@news.xtra.co.nz...
"Jim Granville" <jim.granville@designtools.co.nz> wrote in message
news:3FB1470C.F22@designtools.co.nz...
I think item 4) was to cover capture of the counter at any
instant, and to cover the carry ripple.
I'm with Peter in questioning 4).
Carry ripple is certainly long, but this is on the .D side, and
determines the NEXT Clock delay. However any Capture is on the .Q side,
and all Q's will be fully sync (no ripple adders )
Capture of both the prescaler, and long counter, can be clock
syncronous, and does not need any enables.

4) is to cover the fact that once you enable the +1 on the long carry
chain
you can't
sample it at the next clock cycle (It won't be ready by then), so you have
to latch the
previous value which is the new count value.

The problem is that I must be able to sample the counter on every arbitary
clock cycle
therefore it must be glitch free.

It wouldn't be easier to always latch the low part?
That is, you build a circuit with a latency of 1 cycle to load a, and then
you have new a+1 result on every cycle.

Something like this:

process (...)
begin
if rising_edge(clk) then
a_low <= a_low + 1;
if (a_low = x"FFFF") then
enable_high <= '1';
else
enable_high <= '0';
end if;
if (enable_high = '1') then
a_high <= a_high + 1;
end if;
late_a_low <= a_low;
end if;
end process;

And the output is
a <= a_high & late_a_low;

Of course, additional logic is needed to load the counter with a predefined
value.

Once you get a (correct) value on a (by the load operation, not shown
above),
a_low maintains the low part of the _next_ count, while a_high has the high
part of the _current_ count.
That is why you need to delay a_low by a clock period.

I've tested a similar approach for a 64 bit counter running >200MHz on a
virtex2 -4 speed grade
although in my case the counter was built from 8 8-bit blocks.

Regards
Francisco

The counter that I need doesn't require a clear but thanks for the
thought,
it needs a load though.


Capture and Clear (can be more application usefull), can
be done in a single clock with a little more .D side logic.

Capture of fractional clocks, to push the time resolve better than
1/clock speed, is challenging, but looks possible in modern FPGA.

-jg

 

[Morten Leikvoll]

"Erez Birenzwig" <erez_birenzwig@hotmail.com> skrev i melding
news:9eUrb.2$%o4.221@news.xtra.co.nz...

Hi,

I'm trying to write some code for a 64 bit counter for a VirtexII.

The problem I'm facing is that it has to run at least at 200MHz, and
therefore
a simple "a = a + 1" doesn't work (Xilinx rate the 64b counter to 114MHz).

I've tried a split approach with four smaller counters and a selector
depending on the carry out of the previous stages but it only got me to
about
180MHz.

Did anyone ever had a similar problem and solved it ?
Unfortunately I'm not familiar with a pipelined implementation, I'll be
happy
to learn one.

Just a thought:
Run a 63 bit at clk/2 (100Mhz). reclock the 63 bit result at 200Mhz with a
clock enable on the second 200MHz clock in the 100MHz domain. Use a logic
accessible 100Mhz clock as bit0. Should work, shouldn't it?

 

[Peter Alfke]

Why are we re-inventing complicated solutions to a simple problem?
A perfectly synchronous counter solution has been described, using a
2-(or3-)bit front end driving the enable for the rest of the bits.
If you want a fast counter (not incrementer!) then there is nothing to
be improved or fixed. It's the best solution!

Peter Alfke