Re: need fast FPGA suggestions





John_H wrote:

You can feed a 500 MHz clock to a Spartan3 style device, use a divide-
by-2 in the DCM, and clock the output I/O blocks with the 250MHz clock
in DDR mode. You just need to handle the logic to deal with odd/even
starts and stops.

We don't need to distribute a 500 MHz clock, 250 or even 125 with LVDS would be fine.

I don't think you'll have power problems running only 32 channels of
13-bit counters but a power analysis will give you an idea of the
actual need (XPOWER tool?).

Spartan 3, huh? I'm just a little more comfortable with that, as I just did a migration to Spartan IIE (always on the trailing edge!) I can even get those in TQFP's, which I can mount and rework myself. I'm avoiding BGAs.

I will have to look into the implications of using Spartan 3E on this.
If the counters are running at 250 MHz, then the granularity of timing timing settings is 4 ns, which may well be tolerable. If they need finer resolution, then there are ways to fudge that with the DDR.
So, you think a 13-bit counter feeding a 13-bit identity comparator will work at 250 MHz? (I've never pushed the speeds on these FPGAs at all, all of by previous projects were very relaxed by comparison, like 40 MHz.)

The counters are simple. The DDR is straightforward. The boundary
conditions are limited.

If you want better than 2ns resolution, you can use the SERDES
channels on a Virtex-5FX style part (much more expensive) and hit
resolution under 300ps; a nice option for a piece of test equipment
where one-up price is of little consequence compared to the
engineering time but harder to swallow for production.

Yeah, I really don't think we can handle $2000 IC's. This isn't a real production project, we might build 5 of them at a time, but we are still cost-sensitive.

Thanks,

Jon

.



Relevant Pages

  • Re: [patch 00/21] hrtimer - High-resolution timer subsystem
    ... Right now the primary function of the state is to tell whether the timer ... > Of course if you consider the possibility of including high resolution ... problem requires solving problems in the clock abstraction first, ...
    (Linux-Kernel)
  • Re: [PATCH] ktimers subsystem 2.6.14-rc2-kt5
    ... > a clock with a better resolution. ... > resolution than the physical clock has. ... reaches this count the timer is expired. ... OTOH We could also do this at the timer interrupt: ...
    (Linux-Kernel)
  • Re: Need to implement a calendar clock with millisecond resolution, please help.
    ... true, as I am a newbie, not even a real programmer), but I need to ... implement a calendar time clock with a millisecond resolution. ... system include clock, delay(), gettimeofday, msleep, ...
    (comp.lang.c)
  • Re: Q about noise in time interval measurement averging
    ... I have a PIC measuring a time interval to 25ns resolution, ... I cant seem to recall how the noise reduces with increasing samples, ... your need to know the sense of the rotation as well as it's speed. ... My own inclination would be to go for a faster clock - using ...
    (sci.electronics.design)
  • Re: Post processing of NTP data...
    ... Some real-time operating systems may allow you to achieve finer resolution at that level, but I don't know if any of them are going to let you get down to the level you want. ... When queried as to the time using O/S services, these systems respond with the current value of the clock register. ... is from a bad batch, a good batch or an indifferent batch. ...
    (comp.protocols.time.ntp)

Loading