Fast Counter

[Jessica Shaw]

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

 

[Rob Gaddi]

On 9/7/2011 12:07 PM, Jessica Shaw wrote:

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

A 400 MHz counter in an FPGA is difficult. 800 MHz is probably impossible.

Possibly run 4 14-bit, 200 MHz counters in parallel on 4 different clock
phases and then sort out the outputs after the stop happens?

--
Rob Gaddi, Highland Technology
Email address is currently out of order

 

[Bart Fox]

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]

Hi,

Why is it dfficult?

Jess

 

[Rob Gaddi]

On 9/7/2011 4:28 PM, Jessica Shaw 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?

A mid-range sedan costs $12,000 or so, and mostly just works. A jet
engine costs about $2M, and requires pretty regular maintenance.

A company called Achronix makes crazy high-speed FPGAs that might be
able to do what you're talking about. I've never talked to them about
pricing, but I wouldn't expect to be able to walk away with any of their
stuff for under $10K, and wouldn't be shocked it it's well higher.

Second, what should be the good solution?

FPGAs are fundamentally not that fast, certainly far slower than the
equivalent ASIC at the same technology. Generally, the solution to
speed problems in FPGAs is to find ways to parallelize your task instead
of brute forcing it with MHz. Hence my first response to you.

By the way, the question of what is it you're actually trying to do is
one of those things that always comes up. It sounds as if you're trying
to basically make a high-resolution stopwatch. There are all manner of
dirty tricks that can be played to make that happen that don't require a
preposterously high-speed clock. "Time digital converter" are your
Google terms.

jess

--
Rob Gaddi, Highland Technology
Email address is currently out of order

 

[Jessica Shaw]

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]

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

 

[Jessica Shaw]

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

 

[Rob Gaddi]

On 9/8/2011 12:15 PM, Jessica Shaw 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.

Thanks
jess

Different phases as in, you run your external 200 MHz clock into a PLL
(or DLL, depending on what the FPGA you're using has, they'll serve the
same purpose) and bring out four 200 MHz clocks, each 1.25 ns apart from
the next (4 * 1.25 ns = 5 ns = 1/200 MHz).

Then you have four counters with four enable flip-flops, each running on
a different one of those clock phases. Your start and stop pulses
control the enable flops.

Then you put some downstream logic on one of those clock phases that,
after you've gotten a stop pulse, adds up the results of those four
counters. The fact that you'll have some number of counters with N
counts, and some with N-1 gives you an effective 1.25 ns resolution on
your timing.

--
Rob Gaddi, Highland Technology
Email address is currently out of order

 

[Jessica Shaw]

A timing waveform or block diagram would work too
jess

 

[KJ]

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]

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.

 

[Martin Thompson]

valtih1978 <do@not.email.me> writes:

Because FPGA gates _are emulated_.

I'm not sure that's a fair representation! True, there are no
user-accessible "gates" as such, but there are a plethora of low-level
configurable logic elements of various sorts, which are real enough!

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.

FPGAs are intended to *implement* some logic. If you want to use it for
the narrow world of emulating an ASIC, that's fine.

I don't. I build products with them.

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.

Those who target FPGAs must be well aware of these resources, so that
they use them to their best advantage. Just throwing an ASIC netlist at
them will not realise the sort of results that an experienced and
talented FPGA user will. (I had "designer" rather than "user" in here
first, but that might cause confusion with the paragraph below...)

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,

I assume you mean the designers of the FPGA silicon, not people like me
who design logic to in said silicon. Who are often called FPGA
designers as well...

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.

On the upside, they are

* Cheap enough
* Small enough
* Low power enough

for an awful lot of real applications outside of "emulating ASICs".

And they have vastly lower NRE and are completely field reconfigurable
(unlike ASICs).

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

 

[valtih1978]

but there are a plethora of low-level
configurable logic elements of various sorts, which are real enough!

In which point do I say otherwise?

FPGAs are intended to *implement* some logic. If you want to use it
for the narrow world of emulating an ASIC, that's fine. I don't. I

build products with them.

On the upside, they are * Cheap enough * Small enough * Low power
enough * And they have vastly lower NRE and are completely field

reconfigurable (unlike ASICs).

That is why we emulate our circuits in FPGAs rather than produce them in
silicon. Please, do not confuse the emulation with simulation (aka
prototyping). Both emulation and simulation mimic some object. The
difference is that in simulation (prototyping) you study the behaviour,
including internals of your model. Using emulator, you do not care about
the model. The emulation means (at least as how understand it) that
there is some SW (machine or circuit) that runs on top of another, HW
layer (machine or circuit). Emulated part will be more flexible but
executes 10x slower.

The prototypes are simulations implemented in FPGA. FPGAs are ideal to
speed up simulation. But, they are also ideal for emulating any user
logic outside the domain of logic simulation.

 

[Andy]

Valtih,

I don't believe your definitions of emulation and simulation are
commonly used in industry, but I see your point (with your
clarification).

I agree with Martin however, that FPGAs IMPLEMENT logic. We often
think of them as emulating gates, but modern FPGA synthesis tools do
not compile a design down to gates and then emulate the (groups of)
gates with FPGA resources, they compile the design to FPGA resources
directly. Descriptions of the implementation (ntelists, etc.) often
use familiar sounding gate terminology, but that is a documentation
artifact, not based on how the synthesis tool does its job.

The implemented logic may be used as a prototype for an ASIC that it
is emulating (industry standard definition thereof, as a replacement
for, or augmentation of, simulation). Or the implemented logic may be
the final product. If you designed a board 20+ years ago, you would
not say that PALs and SSI circuits (74xx) emulated the logic you
wanted, you would say they IMPLEMENTED the logic you wanted. When I
was in college, we studied IMPLEMENTING logic functions (often
represented as series of gates, truth tables, sum-of-products, etc.)
using SSI components like multiplexers, decoders, etc. When I got into
industry, PALs/PLAs were the main tool of choice, and such tricks were
"obsolete". Little did I know that in a few short years, I would be
dusting off those same tricks designing FPGAs (before FPGA synthesis
got much better).

Throwing a figure like "10x slower" around is a bit short-sighted.
They can be 10x slower, but they can also be much less slower,
depending on what you are trying to accomplish, and on the available
resources in the FPGA device.

Andy

 

[Jessica Shaw]

Rob Wrote

Different phases as in, you run your external 200 MHz clock into a PLL
(or DLL, depending on what the FPGA you're using has, they'll serve the
same purpose) and bring out four 200 MHz clocks, each 1.25 ns apart from
the next (4 * 1.25 ns = 5 ns = 1/200 MHz).

Then you have four counters with four enable flip-flops, each running on
a different one of those clock phases.  Your start and stop pulses
control the enable flops.

Then you put some downstream logic on one of those clock phases that,
after you've gotten a stop pulse, adds up the results of those four
counters.  The fact that you'll have some number of counters with N
counts, and some with N-1 gives you an effective 1.25 ns resolution on
your timing.

Will I have four stop and start pulses to control the flip flops? I
did not understand the part saying that The fact that you'll have some
number of counters with Ncounts, and some with N-1 gives you an
effective 1.25 ns resolution on your timing.


Thans
jess

 

[Jessica Shaw]

Hi KJ,

You are suggesting that I should use 800MHz clock and divided into
four 200MHz clocks. Each clock will be running a counter. A two bit
counter will be running on 800 MHz clock. Will the four counters have
their own enbale, stop and start signals? Is free running counter is
the "counter" defined as signal?

jess

 

[valtih1978]

Thank you explaining the difference between implemention and emulation.
Indeed, personal computers, ASICs, FPGAs are the technologies to
implement user algorithms. You just say: implement that for me and
compiler does the job. This is ok, but, I do not see why ASICs are
different in this respect. There is Design Compiler. It does the same
thing as FPGA-oriented synthesis - it maps HDL to the gates available in
target technology (see them packed in LUTS, FPGA in technology view).

More importantly, this abstraction from implementation details brings us
away from from the question: _why universal computers are ten times
slower than the special-purpose ones?_ Highlighting that synthesizer
produces "soft gates" out of RTL description unveils the virtual
computation on top of native one. This is important here because it
answers Jessica's question.

 

[valtih1978]

Support from the major FPGA vendor is very good. It is natural because
HW achieves its supercomputer performance through the fine grain
parallelism. It consists of millions of tiny parallel processors - the
gates. Thus, it seems impossible to extract the available parallelism
out of RTL description without compiling it into a netlist. Should it be
a target fpga or virtual technology.

Let's suppose you compile RTL directly into target fpga technology right
away and, thus, achieve the most optimal FPGA implementation ever
possible. How do you explain Jessica why you are still 10x behind ASIC?

 

[valtih1978]

Actually, it was rhetoric question with the purpose to show that whether
mapping to FPGA is immediate or undergoes virtual gate representation is
not important for FPGA vs. ASIC performance.

Regarding your marketing manifest, adding that "FPGAs are designed such
that the end user does not have direct control all the way down to the
transistor level" does not add very much to it. How do you run you
design on FPGA if you have no control over its "gates"? Actually, it
says that "we do not allow you to turn our general-purpose computer into
app-specific one by design". I'm sure, that the problem is not a design.
You cannot do that in principle. FPGA stays a fixed, hardwired
general-purpose piece of computer. It executes user app at the higher
level. In other words, it emulates user circuit rather than implements
it natively. As any emulation, it is is 10x slower. 'Niches' do not
change this principle.

So, you cannot bypass this picture.