Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   VHDL (http://www.velocityreviews.com/forums/f18-vhdl.html)
-   -   Fast Counter (http://www.velocityreviews.com/forums/t753730-fast-counter.html)

Jessica Shaw 09-07-2011 07:07 PM

Fast Counter
 
Hi,

I need a 700 MHz to 800Mhz synchronous 16 bit counter. The counter
will also have a Start, Reset and Stop pins.

Reset will intialize the counter to zero. Start will let the counter
run on each rising edge of the 700 or 800 Mhz clock. And stop will
stop the counter and user will be able to read the value.

I do not know

1. What FPGA or CPLD will be able to do this task at the above
mentioned high frequency?
2. Do I need a PLL inside the FPGA or CPLD to produce such kind of
clock?
3. How can I generate this kind of clock?

Any advice will be appreciated.

jess

Jessica Shaw 09-07-2011 08:38 PM

Re: Fast Counter
 
Hi,

Why is it dfficult?

Jess

Bart Fox 09-07-2011 10:25 PM

Re: Fast Counter
 
On 07.09.11 13:38:12 Jessica Shaw <jsscshaw88@gmail.com> wrote:
> Hi,
>
> Why is it dfficult?

Why is it difficult to build and drive a car with 1000 km/h (620 mph)?
There are physical limits.
In both cases.

regards,
Bart

Jessica Shaw 09-07-2011 11:28 PM

Re: Fast Counter
 
Hi,

ok, so you can get a jet engine car but it will be difficult to drive
it on the road. So, what are the difficulties with making such a
FPGA?

Second, what should be the good solution?

jess

KJ 09-08-2011 03:11 AM

Re: Fast Counter
 
On Sep 7, 7:28*pm, Jessica Shaw <jsscsha...@gmail.com> wrote:
> Hi,
>
> ok, so you can get a jet engine car but it will be difficult to drive
> it on the road. So, what are the difficulties with making such a
> FPGA?
>


The short answer is that there are tradeoffs that are based on
technology as well as market demand. The FPGA companies' customers
make use of capabilities that are unique to FPGAs and are willing to
compromise on things like top speed or low power consumption.

Providing things like re-programmability and a fairly generic pool of
logic that can implement basically any arbitrary function which FPGAs
do quite well doesn't come 'free'. Historically, the price to be paid
has meant that you will pay a higher piece price, run slower and
consume more power than you would if you have the resources and
business case to develop a custom single function part. Without
getting into a debate about the merits of each cost, suffice it to say
that there is sufficient market demand for such programmable products
to keep companies in business and profitable.

There are many niches that one can play in the programmable logic
world and be profitable. Some of these niches involve providing lower
power or higher performance than some other companies FPGA. However,
within each niche product, you'll find something that you can't do (or
can't do well) with that part that you can with some other part.
Before there were even FPGAs, there were PLDs which provide much the
same type of functionality but were blazingly fast compared to those
first FPGAs...but again, there were tradeoffs, notably the amount of
logic that could be implemented in a single device.

So, in the end, if you're a user of an FPGA, it really doesn't matter
"what are the difficulties with making such a FPGA" as you asked.
Your job is to find the FPGA that has the right set of features for
your application.

> Second, what should be the good solution?
>

Before there can be a solution there must first be a full discovery of
what the constraints really are so nobody here will be able to
confidently offer up what will be a 'good' solution for you. You can
get possible solutions that happen to work for you, but since we don't
know your constraints we don't really know if any proposed solution
would really be 'good'.

For example, you didn't state any latency requirement on when the
count must be valid relative to the assertion of 'stop'. If there is
none, than one can play the simple game of having four counters
running on different phases of 200 MHz. At the end, simply add the
value of the four counters to get the final result.

This approach would obviously take more logic than a hypothetical
single 16 bit counter, but since you have not stated any logic
resource constraints for the counter one would have no idea of whether
or not this approach is 'good' for you. So logic resource are another
possible constraint.

Counters do not have to be binary, a 16 bit LFSR will run quite fast
but then it requires interpretation of the output in order to figure
out what the binary equivalent value...but maybe that's OK in your
application. So counting sequence is another possible constraint.

There likely is a programmable part that can implement a full 16 bit
binary counter in minimal resources but maybe the cost is too high and
it makes the product not profitable so that part can't be used.

As you can see, there are likely all kinds of constraints that one may
not necessarily realize up front. It is up to you to understand your
function and performance goals, the constraints that you must live
within and come up with the optimal solution...that's what is known as
engineering. In short, you have to look at tradeoffs.

Kevin Jennings

jeppe 09-08-2011 09:15 AM

Hi

If you implement the two least signigicant bit as a Johnson counter will you "only" need to implement a 14-bit 200MHz counter for the rest of the bits.

your welcome

Jessica Shaw 09-08-2011 07:15 PM

Re: Fast Counter
 
> Kevin Jennings wrote:
> For example, you didn't state any latency requirement on when the
> count must be valid relative to the assertion of 'stop'. *If there is
> none, than one can play the simple game of having four counters
> running on different phases of 200 MHz. *At the end, simply add the
> value of the four counters to get the final result.
>


Can you advice more on how can I use four counters running on
different phases of 200MHz. I am little confused about different
phases. Can you advice some application notes or examples.

Thanks
jess


Jessica Shaw 09-08-2011 08:36 PM

Re: Fast Counter
 
A timing waveform or block diagram would work too
jess

KJ 09-11-2011 01:05 AM

Re: Fast Counter
 
On Sep 8, 3:15*pm, Jessica Shaw <jsscsha...@gmail.com> wrote:
> > Kevin Jennings wrote:
> > For example, you didn't state any latency requirement on when the
> > count must be valid relative to the assertion of 'stop'. *If there is
> > none, than one can play the simple game of having four counters
> > running on different phases of 200 MHz. *At the end, simply add the
> > value of the four counters to get the final result.

>
> Can you advice more on how can I use four counters running on
> different phases of 200MHz. I am little confused about different
> phases. Can you advice some application notes or examples.
>


Actually, you don't need to run four different phases of the clock as
I mentioned, you can run the four counters on the same 200 MHz clock
that is phase locked to the 800 MHz which might be a simpler situation
to describe in this forum. Either approach is viable, there can be
other ways to accomplish the same thing as well..

Start with a free running two bit counter that is clocked by your 800
MHz clock. If on a particular clock cycle you want to advance your
counter by 1 then what you would do is set a bit in a four bit
vector. Something like this...

signal Counter_Enable: std_ulogic_vector(0 to 3);
signal Counter: natural range Counter_Enable'range;
....
if rising_edge(Clock_800MHz) then
-- Free running counter
if (Reset = '1') or (Counter = 3) then
Counter <= 0;
Counter_Enable <= (others => '0');
else
Counter <= Counter + 1;
end if;
Counter_Enable(Counter) <= Count_By_1;
end if;

Now assume that you have a 200 MHz clock that is phase locked to the
800 MHz clock. The first thing you would want to do is resynchronize
the Counter_Enable to the slower clock like this...

Counter_Enable_Sync_200M <= Counter_Enable when
rising_edge(Clock_200M);

The reason for this is that the individual bits of 'Counter_Enable',
since they are clocked by the 800 MHz clock, will be changing at times
that will make meeting timing difficult. By syncing them to the 200
MHz clock, now you have a counter enable that will be there for an
entire 200 MHz clock cycle. So you use those to bump the individual
counters like this...

for i in Counter_Enable_Sync_200M'range loop
if (Counter_Enable_Sync_200M = '1') then
Counter_200M(i) <= Counter_200M(i) + 1;
end if;
end loop;

At the end, you add the four counters up to get the final output...

Counter_Out <= Counter_200M(0) + Counter_200M(1) + Counter_200M(2) +
Counter_200M(3)

Also, note that each of the four 'Counter_200M' counters would only
need to be 14 bits rather than 16 since at most they count one time
every four of the 800 MHz clocks.

I've left out some of the details, but outlined it enough that you
should be able to follow the general idea. One other point that
you've left out of your description is what is generating the 700-800
MHz input that you are counting in the first place. What I've
described presumes that you have such a clock cycle and can then
derive the slower clock from that faster clock...maybe that's your
situation, maybe not. Like I said before, you haven't described
enough for anyone to know what problem is being solved.

Kevin Jennings

valtih1978 09-12-2011 09:01 AM

Re: Fast Counter
 
On 7.09.2011 23:38, Jessica Shaw wrote:
> Hi,
>
> Why is it dfficult?
>
> Jess


Because FPGA gates _are emulated_.

You might wonder why ASICs, easily running at 4 GHz today, do only at
400 MHz in case of FPGAs.

FPGAs are intended to emulate the logic. They do it much faster and
more efficiently than SW emulation on usual processor-based (super-)
computers. However, emulation is still achieved through configuration of
the real HW. That means that you must have abudance of HW resources that
may be configured into this or that mode. Some true gates are used as
switches rather than do useful job. Others stay unused because FPGA
designers are not application aware and, therefore, cannot be sure which
resources will be necessary, they cannot optimize placement and routing
for user to minimize the paths. In result, you have 10x larger, more
expensive, power-hungry device than ASIC. It is as much slower because
signals must pass through configuration switches and suboptimal routing,
around unused resources and drive unused gates.

Comp.arch.fpga is the place to ask for FPGA caps.


All times are GMT. The time now is 05:49 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.