need fast FPGA suggestions

Hello, all,

I just got a potential project thrown in my lap. I designed an
all-analog delay generator module, with 32 delays that trigger 32 pulse
widths. So, basically, 64 wide-range programmable one-shots on one
board. LVDS in, ECL out (for legacy gear). These one-shots can be
programmed from about 10 ns to 12 us in several ranges.

Somebody asked, "Gee, couldn't you do that with an FPGA?" Well, a few
years ago, maybe not. So, could anyone suggest some fast FPGAs that can
handle clocks in the 500+ MHz range? I normally work with Xilinx, but
could look at some others, too. I suspect RAM-based FPGAs would be
desirable over one-time programmed. It would not be a problem to use
several smaller FPGAs to keep them from overheating at the high clock
rate. We have forced-air cooling in the equipment, but you lose that
when modules are put on extenders.

The basic circuit would look like a 13-bit counter with a 13-bit preset
register, and a zero comparator. (It could also be a 13-bit counter
that starts at zero, and a preset register that sets the terminal
count.) So, 432 FFs would do 8 channels of this dual one-shot logic.
Half of the FFs would be clocked at the 500+ MHz rate, the other half
would be essentially static.

Thanks in advance for any suggestions!

Jon

On Aug 25, 12:08*pm, Jon Elson wrote:
> Hello, all,
>
> I just got a potential project thrown in my lap. *I designed an
> all-analog delay generator module, with 32 delays that trigger 32 pulse
> widths. *So, basically, 64 wide-range programmable one-shots on one
> board. *LVDS in, ECL out (for legacy gear). *These one-shots can be
> programmed from about 10 ns to 12 us in several ranges.
>
> Somebody asked, "Gee, couldn't you do that with an FPGA?" *Well, a few
> years ago, maybe not. *So, could anyone suggest some fast FPGAs that can
> handle clocks in the 500+ MHz range? *I normally work with Xilinx, but
> could look at some others, too. *I suspect RAM-based FPGAs would be
> desirable over one-time programmed. *It would not be a problem to use
> several smaller FPGAs to keep them from overheating at the high clock
> rate. *We have forced-air cooling in the equipment, but you lose that
> when modules are put on extenders.
>
> The basic circuit would look like a 13-bit counter with a 13-bit preset
> register, and a zero comparator. *(It could also be a 13-bit counter
> that starts at zero, and a preset register that sets the terminal
> count.) *So, 432 FFs would do 8 channels of this dual one-shot logic.
> Half of the FFs would be clocked at the 500+ MHz rate, the other half
> would be essentially static.
>
> Thanks in advance for any suggestions!
>
> Jon

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.

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

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.

If you want slower channels, you can even add prescaling to slow down
the amount of fast-clocked logic.

The possibilities are endless. Your needs are limited.

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

>
> John_H wrote:
>
> 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.)
>

Tight, but probably doable. On a Spartan 3 (fastest speed grade) I'm doing 20 bit full adders and 16-bit magnitude compares at 128 MHz with time to spare.

If you wanted to get excessive, you could run 4 phases of a 250 MHz clock around the chip, use them in pairs to generate 2 possible DDR outputs per channel, and diode OR them into an ECL flip-flop that you clock at 1 GHz to square the timing back up. Something of a power hog, but the Micrel 10EL31s are under $3 a pop.

You could also possibly get subclock resolution by being clever with some tapped carry-chain delay lines. There's an example of this sort of thing in XAPP250. You could use something similar to note how far into your logic clock you were when the input trigger came, and then squirt the same back out after your clocked delays.


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

On Aug 25, 5:29 pm, Jon Elson wrote:
> 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.)

Remember that you can pipeline the comparator. Each LUT can compare
two bits and four (or 8) of those can be combined with another row of
LUTs. Heck I haven't looked hard at the Xilinx parts in awhile, but I
recall that you can use some of the "extra" logic in a CLB to compare
4 bits in two LUTs with one output, then AND 8 of those in a second
level of LUTs. Each level of logic can work with a FF on the output,
you just have to account for that in your compare register setting. I
expect this will run at 250 MHz, but I can't say for sure.

Rick

On Mon, 25 Aug 2008 14:08:20 -0500, Jon Elson wrote:

>Hello, all,
>
>I just got a potential project thrown in my lap. I designed an
>all-analog delay generator module, with 32 delays that trigger 32 pulse
>widths. So, basically, 64 wide-range programmable one-shots on one
>board. LVDS in, ECL out (for legacy gear). These one-shots can be
>programmed from about 10 ns to 12 us in several ranges.
>
>Somebody asked, "Gee, couldn't you do that with an FPGA?" Well, a few
>years ago, maybe not. So, could anyone suggest some fast FPGAs that can
>handle clocks in the 500+ MHz range? I normally work with Xilinx, but
>could look at some others, too. I suspect RAM-based FPGAs would be
>desirable over one-time programmed. It would not be a problem to use
>several smaller FPGAs to keep them from overheating at the high clock
>rate. We have forced-air cooling in the equipment, but you lose that
>when modules are put on extenders.
>
>The basic circuit would look like a 13-bit counter with a 13-bit preset
>register, and a zero comparator. (It could also be a 13-bit counter
>that starts at zero, and a preset register that sets the terminal
>count.) So, 432 FFs would do 8 channels of this dual one-shot logic.
>Half of the FFs would be clocked at the 500+ MHz rate, the other half
>would be essentially static.
>
>Thanks in advance for any suggestions!
>
>Jon


You can do coarse delays by counting at some modest clock frequency,
and get fine delays from a fast-clocked shift register or a simple
external analog vernier. The analog thing can take you down to
picosecond resolution.

You can also double resolution by using both clock edges.

But can you tolerate the 1-clock p-p jitter that you'll get from
asynchronous trigger inputs slamming into a continuous clock?

John

Jon Elson wrote:
> Hello, all,
>
> I just got a potential project thrown in my lap. I designed an
> all-analog delay generator module, with 32 delays that trigger 32 pulse
> widths. So, basically, 64 wide-range programmable one-shots on one
> board. LVDS in, ECL out (for legacy gear). These one-shots can be
> programmed from about 10 ns to 12 us in several ranges.
>
> Somebody asked, "Gee, couldn't you do that with an FPGA?" Well, a few
> years ago, maybe not. So, could anyone suggest some fast FPGAs that can
> handle clocks in the 500+ MHz range? I normally work with Xilinx, but
> could look at some others, too. I suspect RAM-based FPGAs would be
> desirable over one-time programmed. It would not be a problem to use
> several smaller FPGAs to keep them from overheating at the high clock
> rate. We have forced-air cooling in the equipment, but you lose that
> when modules are put on extenders.
>
> The basic circuit would look like a 13-bit counter with a 13-bit preset
> register, and a zero comparator. (It could also be a 13-bit counter
> that starts at zero, and a preset register that sets the terminal
> count.) So, 432 FFs would do 8 channels of this dual one-shot logic.
> Half of the FFs would be clocked at the 500+ MHz rate, the other half
> would be essentially static.
>
> Thanks in advance for any suggestions!
>
> Jon

Hej Jon

How about AFPGA instead of FPGA?:

Achronix-ULTRA:
http://www.achronix.com/products.html

Achronix preps 2-GHz Asynchronous FPGA for sampling in 2007:
http://www.pldesignline.com/news/186700955

Asynchronous VLSI and Architecture, Cornell University: Asynchronous
Field-Programmable Gate Arrays (AFPGAs):
http://vlsi.cornell.edu/fpga.php
Quote: "...integrated pipelining support..."

Programmable Asynchronous Pipeline Arrays (2003) John Teifel, Rajit Manohar:
http://citeseer.ist.psu.edu/teifel03programmable.html

Glenn

Jon Elson wrote in news:48B30324.2000603-at-wustl.edu:

> Hello, all,
>
> I just got a potential project thrown in my lap. I designed an
> all-analog delay generator module, with 32 delays that trigger 32
> pulse widths. So, basically, 64 wide-range programmable one-shots on
> one board. LVDS in, ECL out (for legacy gear). These one-shots can
> be programmed from about 10 ns to 12 us in several ranges.
>
> Somebody asked, "Gee, couldn't you do that with an FPGA?" Well, a few
> years ago, maybe not. So, could anyone suggest some fast FPGAs that
> can handle clocks in the 500+ MHz range? I normally work with Xilinx,
> but could look at some others, too. I suspect RAM-based FPGAs would
> be desirable over one-time programmed. It would not be a problem to
> use several smaller FPGAs to keep them from overheating at the high
> clock rate. We have forced-air cooling in the equipment, but you lose
> that when modules are put on extenders.
>
> The basic circuit would look like a 13-bit counter with a 13-bit
> preset register, and a zero comparator. (It could also be a 13-bit
> counter that starts at zero, and a preset register that sets the
> terminal count.) So, 432 FFs would do 8 channels of this dual
> one-shot logic. Half of the FFs would be clocked at the 500+ MHz rate,
> the other half would be essentially static.
>
> Thanks in advance for any suggestions!

You might also like to consider using a part with a high speed serdes,
e.g. Stratix-nGX, or Virtex-nFX, etc. This allows you to sample at some
GHz, with a convenient, sensitive differential input. You can
synthesise any delay you want in multiples of the sampling period, by
rotating the internal parallel bus. The SERDES output will probably be
CML, but that is pretty easy to interface to ECL.

AFAICT, this will give you close to an order of magnitude better
performance than any other FPGA based approach.

Regards,
Allan

Glenn,

I have tried hard to get data on the Achronix parts, but have never
succeeded in obtaining any useful/detailed information at all, nor have
I ever received any kind of a response from the company when requesting
information. Have you come across a source of substantive data on these
mysterious devices?

Robert J
__________________________________________________ _________________

Glenn Møller-Holst wrote:

> Hej Jon
>
> How about AFPGA instead of FPGA?:
>
> Achronix-ULTRA:
> http://www.achronix.com/products.html
>
> Achronix preps 2-GHz Asynchronous FPGA for sampling in 2007:
> http://www.pldesignline.com/news/186700955
>
> Asynchronous VLSI and Architecture, Cornell University: Asynchronous
> Field-Programmable Gate Arrays (AFPGAs):
> http://vlsi.cornell.edu/fpga.php
> Quote: "...integrated pipelining support..."
>
> Programmable Asynchronous Pipeline Arrays (2003) John Teifel, Rajit
> Manohar:
> http://citeseer.ist.psu.edu/teifel03programmable.html
>
> Glenn

John Larkin wrote:
> You can do coarse delays by counting at some modest clock frequency,
> and get fine delays from a fast-clocked shift register or a simple
> external analog vernier. The analog thing can take you down to
> picosecond resolution.
>
> You can also double resolution by using both clock edges.
>
> But can you tolerate the 1-clock p-p jitter that you'll get from
> asynchronous trigger inputs slamming into a continuous clock?


I didn't think so, that's why I designed a hideous analog delay circuit,
much like the no-longer-available-at-a-sane-price AD9501. (A current
source,
integrating cap, comparator and DAC) I ended up with 1200 components on
one board for 64 of these delay circuits. And, it uses the difficult to
mount AD CMP603 in the 3 mm square CSP that gave me FITS getting a
couple boards working. Many, many, many shorts and opens!

But, aparently, 2 ns of jitter is NOT a problem. Only the initial delay
will suffer the jitter, the width of the second timer will always be
synched to the clock, and so the width won't vary. That was the more
critical part of it.

I'm still researching how you do this with the DDR feature.

Jon