Implementing a very fast counterin VirtexII

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.

"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.

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.

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.

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.

"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.
>

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.
>
>
>
>  
>

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 ----------

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.

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.