need fast FPGA suggestions

Regarding the long counters at 250 MHz: I've only worked with Spartan 3s, not the Virtexes, but I was under the impression that the DSP48 blocks tendto be built for this sort of thing. Granted, using a full MAC block as a counter (possibly a down counter) seems to be overkill, but I can't see where you'd need them for anything else.

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

On Wed, 27 Aug 2008 16:10:21 -0700 (PDT)
John_H wrote:

> On Aug 27, 2:45*pm, Jon Elson wrote:
> >
> > Yes, I think you are right, and I greatly appreciate the data points
> > about the 206 MHz and the 10-bit carry. *The circuit I need to implement
> > is REALLY simple, but gets a bit more complicated when you add in the
> > logic to handle the DDR. *The SERDES components in the Virtex look like
> > they would be ideal to handle this, and instead of only having an X2
> > option with DDR, this makes an X8 option nearly as simple. *The part
> > cost, all by itself, is not that terrible, the smaller Virtex chips are
> > around $200. *The other problem, however, is we have no capability or
> > experience with BGAs, and would have to send them out. *That at least
> > doubles the cost!
> >
> > Thanks again for the info!
>
> 1) The Virtex is a good way to go; the SERDES will work for you as
> long as your minimum delays are met (same is true of shorter delay DDR
> version).
> 2) I thought you had 32 channels
> 3) One instantiation is almost the same as 64 in complexity. It's one
> lone module that produces the results for each instance.
> 4) BGAs can give growing pains, but it's the industry's current sweet-
> spot. If not now, than a few more months down the road.
>
> I'd personally be happy to crank out a design like this in the
> Spartan3x series, but for a 5-up production the added speed and
> functionality of the Virtex is a good win.

On Wed, 27 Aug 2008 16:54:55 -0500, Jon Elson wrote:

>
>
>John Larkin wrote:
>> You might consider this trick: when a trigger comes in, start an
>> oscillator, and use that to clock the FPGA. Then time out with
>> counters, and use some fractional-clock trick if you need sub-clock
>> delay or width resolution.
>>
>> I've done this with LC oscillators and coaxial ceramic resonator
>> oscillators; both can be started essentially instantly and can have
>> pretty good jitter performance. The resulting FPGA logic can be pretty
>> simple.
>But, we have 32 independent inputs, with no time correlation. Not
>enough global clock trees to handle that.
>
>Jon

Oh, 32 separate triggers. Stick with analog ramps?

Some of the LVDS line receivers make might fine fast and cheap
comparators, duals even. So could probably do it all in cmos these
days, fairly simple stuff.

Trigger fires flipflop, turns ramp loose; ramp drives two comparators,
which drive a logic gate to make rising/falling output edges. 2nd
comparator clears flipflop. 64 DAC channels program the mess, not bad
if you use serial octal dacs. Figure 2 square inches per channel to be
generous, so it's an 8x8" board.



John

John Larkin wrote:

> Oh, 32 separate triggers. Stick with analog ramps?
>
> Some of the LVDS line receivers make might fine fast and cheap
> comparators, duals even. So could probably do it all in cmos these
> days, fairly simple stuff.
>
> Trigger fires flipflop, turns ramp loose; ramp drives two comparators,
> which drive a logic gate to make rising/falling output edges. 2nd
> comparator clears flipflop. 64 DAC channels program the mess, not bad
> if you use serial octal dacs. Figure 2 square inches per channel to be
> generous, so it's an 8x8" board.

Analog is a candidate, but the OP mentioned a 100:1 dynamic range.
Maybe some range-sw caps ?

Anyone seen Vos vs Common Mode voltage plots for LVDS channels
in FPGAs ? Cross talk figures ?

-jg

On Thu, 28 Aug 2008 13:06:02 +1200, Jim Granville
wrote:

>John Larkin wrote:
>
>> Oh, 32 separate triggers. Stick with analog ramps?
>>
>> Some of the LVDS line receivers make might fine fast and cheap
>> comparators, duals even. So could probably do it all in cmos these
>> days, fairly simple stuff.
>>
>> Trigger fires flipflop, turns ramp loose; ramp drives two comparators,
>> which drive a logic gate to make rising/falling output edges. 2nd
>> comparator clears flipflop. 64 DAC channels program the mess, not bad
>> if you use serial octal dacs. Figure 2 square inches per channel to be
>> generous, so it's an 8x8" board.
>
>Analog is a candidate, but the OP mentioned a 100:1 dynamic range.
>Maybe some range-sw caps ?
>
>Anyone seen Vos vs Common Mode voltage plots for LVDS channels
>in FPGAs ? Cross talk figures ?
>
>-jg

We did some experiments on Spartan 3's, running Vccio at 3.3 to 3.5
volts. It sure looked like the LVDS inputs were good
almost-rail-to-rail comparators. I was impressed.

We didn't measure Vos, as we were just interested in using them as the
comparators in analog ramp circuits, to generate sub-ns tunable
delays, and we assumed we'd calibrate out any offsets. Linear analog
ramp goes onto one side of an lvds input, dac driving the other side.

We did find that they have a lot of jitter when the compare happens
anywhere near the edge of any of the on-chip clocks. With a bunch of,
say, 25 ns ramps coming in, you might expect pretty good jitter, 40 ps
RMS maybe, but with delay zones that peak in the 100 ps range as a
result of crosstalk from clocks or adjacent channels. Not too bad, but
it wasn't good enough for our applications.

John

On Aug 27, 5:45 pm, Jon Elson wrote:
> Andrew FPGA wrote:
> >>So, you think a 13-bit counter feeding a 13-bit identity comparator will
> >>work at 250 MHz?
>
> > Others have said it may be possible but what they fail to acknowledge
> > is the large amount of extra design effort and care required to get
> > there. 250 MHz is really pushing the limits in spartan 3e in my
> > experience. You may have to work very hard to get there: for example I
> > have just finished a distributed arithmetic filter design, that has
> > only 1 LUT level between flops and after a lot of effort I got it to
> > run at 206 MHz in a sp3 1600e. I can see how to get to 220MHz, but
> > beyond that I don't know. The longest carry chain is 10 bits.
>
> > I had to bypass synthesis and instantiate xilinx primitives directly
> > to gaurantee my logic was implemented in 1 LUT level. Then I had to
> > manually floorplan the design - placing each flop with the
> > corresponding LUT by hand( I uses RLOC's embedded in the VHDL source).
> > The automatic placer didn't always place the LUT with the FLOP so you
> > end up with 2 routes which kills the timing completely.
>
> Yes, with 64 instantiations of the circuit on the FPGA, I really DON'T
> want to deal with this!
>
>
>
> >>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.
>
> > If its such low volumes just take the unit cost hit and move to a
> > Virtex part. How valuable is your time?
>
> Yes, I think you are right, and I greatly appreciate the data points
> about the 206 MHz and the 10-bit carry. The circuit I need to implement
> is REALLY simple, but gets a bit more complicated when you add in the
> logic to handle the DDR. The SERDES components in the Virtex look like
> they would be ideal to handle this, and instead of only having an X2
> option with DDR, this makes an X8 option nearly as simple. The part
> cost, all by itself, is not that terrible, the smaller Virtex chips are
> around $200. The other problem, however, is we have no capability or
> experience with BGAs, and would have to send them out. That at least
> doubles the cost!

You don't have to use Virtex to get SERDES. The low cost Lattice
family has SERDES and should be able to do what you are looking for at
a *much* lower price.

Rick

John_H wrote:
> On Aug 27, 2:45 pm, Jon Elson wrote:
>
>>Yes, I think you are right, and I greatly appreciate the data points
>>about the 206 MHz and the 10-bit carry. The circuit I need to implement
>>is REALLY simple, but gets a bit more complicated when you add in the
>>logic to handle the DDR. The SERDES components in the Virtex look like
>>they would be ideal to handle this, and instead of only having an X2
>>option with DDR, this makes an X8 option nearly as simple. The part
>>cost, all by itself, is not that terrible, the smaller Virtex chips are
>>around $200. The other problem, however, is we have no capability or
>>experience with BGAs, and would have to send them out. That at least
>>doubles the cost!
>>
>>Thanks again for the info!
>
>
> 1) The Virtex is a good way to go; the SERDES will work for you as
> long as your minimum delays are met (same is true of shorter delay DDR
> version).
> 2) I thought you had 32 channels
What we have is 32 inputs. Each input starts an independent and
individually adjustable delay, at the end of that delay a pulse of a
settable width comes out. So, the delay and the width circuit are
essentially digital one-shots, and basically the same. The only
difference would be the delay has an asynchronous input, the width is
totally synchronous.

> 3) One instantiation is almost the same as 64 in complexity. It's one
> lone module that produces the results for each instance.
As long as you don't need to go into the chip viewer and manually route
anything to meet timing, yes. I REALLY do not want to have to do that,
as Andrew apparently needed to do on a Spartan 3 project.

> 4) BGAs can give growing pains, but it's the industry's current sweet-
> spot. If not now, than a few more months down the road.
>
> I'd personally be happy to crank out a design like this in the
> Spartan3x series, but for a 5-up production the added speed and
> functionality of the Virtex is a good win.

Well, given the serdes function of the Virtex, maybe we can go 1 ns
input and output resolution, with only 125 MHz clock on the
counter/comparator. My boss would really love that. The smaller Virtex
seem to come in a 1mm-pitch BGA, maybe I can even learn how to do that
myself. Since the balls are only around the perimiter, it might be
visibly inspectable. I'll have to do more research to find out what is
practical.

Jon

Jim Granville wrote:
> John Larkin wrote:
>
>> Oh, 32 separate triggers. Stick with analog ramps?
>>
>> Some of the LVDS line receivers make might fine fast and cheap
>> comparators, duals even. So could probably do it all in cmos these
>> days, fairly simple stuff.
>>
>> Trigger fires flipflop, turns ramp loose; ramp drives two comparators,
>> which drive a logic gate to make rising/falling output edges. 2nd
>> comparator clears flipflop. 64 DAC channels program the mess, not bad
>> if you use serial octal dacs. Figure 2 square inches per channel to be
>> generous, so it's an 8x8" board.
>
>
> Analog is a candidate, but the OP mentioned a 100:1 dynamic range.
> Maybe some range-sw caps ?
>
Well, it is all designed and the board is layed out. I used the AD
CMP603 single fast comparator. A bear to mount, but a very fine chip
for the purpose. It DOES use 2 range switching caps, plus stray
capacitance as the lowest cap value, plus 2 selections of
current-programming resistor.

THEN, my boss said -- "Hey, couldn't you do that with an FPGA?"

> Anyone seen Vos vs Common Mode voltage plots for LVDS channels
> in FPGAs ? Cross talk figures ?
I guess you could measure it yourself.

Jon

On Aug 28, 8:30*am, rickman wrote:
>
> You don't have to use Virtex to get SERDES. *The low cost Lattice
> family has SERDES and should be able to do what you are looking for at
> a *much* lower price.

While it's true the 3+Gb/s high speed serial channels are available in
the Lattice parts (my first Lattice design has started in the ECP2M -
yay!) the SERDES referred to in the Virtex parts for these posts are -
unless I'm sincerely mistaken - the serializer/deserializer elements
built into the general IOBs. The standard I/Os end up with 800Mb/
s-1Gb/s data rates (pulling these numbers from memory) with a simpler
interface than the MGTs or similar RocketIO that can far exceed the
general I/O data rates.

Even in the lattice part, 32 channels of receive and 32 channels of
transmit is costly in the 3Gb/s SERDES channels.

- John_H

Il 25/08/2008 21.08, Jon Elson ha scritto:

> 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

I agree the SERDES solution is more elegant and powerful.

But, just for a comparison of what can be done with cheap parts...

In the summer I had some spare time... just for fun, I (almost) did a
simple logic analyzer using a Spartan3E500, -4 (slower), using a Nexys2
board. A 32 channel, 400 Mhz, 16 Mbytes buffer, RLE compressed, high
speed USB 2.0 logic analizer at $99. Not bad!

Never had time to do the PC software part and finish some pieces...
maybe next holidays if it's raining...

Using the tecnique shown in XAPP225 (4 "parallel" phase shifted
acquisition, and combinatorial stage to "find" the edge), the design can
easily reach 400 Mhz sampling (100 Mhz clock, 4 phases) on each of 32
input channels. I didn't even try to manually floorplan anything, it was
more than enough for me. Besides, it's for fun!

A single acquisition module uses a 100 Mhz clock and a 90° copy.

For each input channel, you get 4 bits in parallel in output, with the 4
last samples at 400 Mhz effective sampling frequency.

There's still space for RLE compression, triggering unit, external ram
controller, USB slave fifo interface, and a bunch of internal I2C
registers. Should be no problem fitting "just" a delay line made with
counters.

With the last 4 samples available "in parallel" at a much slower clock
(100 Mhz), you can use a mux to "choose" the phase delay you want with
the two least significant bits of the choosen delay.

From there on, it's easy since frequencies are "normal".

How to *output* those.... ehm...

Here is the front-end code (sorry for comments in italian):


`timescale 1ns / 1ps

/*
Cfr. XAPP225.
*/

module sampler_4x #(parameter integer WIDTH = 32)
(
input [WIDTH-1:0] din,
input clk,
input clk_90,
// output
output [(4*WIDTH)-1:0] q
);

wire [WIDTH-1:0] az0, az1, az2;
wire [WIDTH-1:0] bz0, bz1, bz2;
wire [WIDTH-1:0] cz0, cz1, cz2;
wire [WIDTH-1:0] dz0, dz1, dz2;

// sequenze di FF organizzati in modo tale da non aver mai campionamenti
piu' vicini di 0.75*Tclk
// FD: DFF synchronous reset
// FD_1: DFF with Negative-Edge Clock and Synchronous Reset
genvar i;
generate
for (i = 0; i < WIDTH; i = i +1)
begin: gen_ifddr
// fase 0
FD ff_az0(.D(din[i]), .C(clk), .Q(az0[i]));
FD ff_az1(.D(az0[i]), .C(clk), .Q(az1[i]));
FD ff_az2(.D(az1[i]), .C(clk), .Q(az2[i]));
FD ff_az3(.D(az2[i]), .C(clk), .Q(q[i]));
// fase 90
FD ff_bz0(.D(din[i]), .C(clk_90), .Q(bz0[i])); // 0.75T
FD ff_bz1(.D(bz0[i]), .C(clk), .Q(bz1[i]));
FD ff_bz2(.D(bz1[i]), .C(clk), .Q(bz2[i]));
FD ff_bz3(.D(bz2[i]), .C(clk), .Q(q[WIDTH + i]));
// fase 180
FD_1 ff_cz0(.D(din[i]), .C(clk), .Q(cz0[i])); // 0.75T
FD ff_cz1(.D(cz0[i]), .C(clk_90), .Q(cz1[i])); // 0.75T
FD ff_cz2(.D(cz1[i]), .C(clk), .Q(cz2[i]));
FD ff_cz3(.D(cz2[i]), .C(clk), .Q(q[2*WIDTH + i]));
// fase 270
FD_1 ff_dz0(.D(din[i]), .C(clk_90), .Q(dz0[i])); // 0.75T
FD_1 ff_dz1(.D(dz0[i]), .C(clk), .Q(dz1[i])); // 0.75T
FD ff_dz2(.D(dz1[i]), .C(clk_90), .Q(dz2[i])); // 0.75T
FD ff_dz3(.D(dz2[i]), .C(clk), .Q(q[3*WIDTH + i]));
end
endgenerate

endmodule

Jon Elson wrote:
> Well, given the serdes function of the Virtex, maybe we can go 1 ns
> input and output resolution, with only 125 MHz clock on the
> counter/comparator. My boss would really love that. The smaller Virtex
> seem to come in a 1mm-pitch BGA, maybe I can even learn how to do that
> myself. Since the balls are only around the perimiter, it might be
> visibly inspectable. I'll have to do more research to find out what is
> practical.

You could add some pin-redundancy as this seem to have a (relatively)
low number of inputs ?
-jg