need fast FPGA suggestions

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

Jon Elson wrote:

> Jim Granville wrote:
>>
>> 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?"

One nice feature of Analog-retrigger, is the lack of sampling jitter.
A minus is the calibration and drifts

How important is jitter ?

Another hybrid analog approach is to use multiple Gateable Osc, and 
Dividers.
The Osc is DAC controlled over just over 2:1 in Freq, and the divider
takes care of the rest.
This is also easy to calibrate, as you can flip from monostable to 
re-trigger, and use a longer timebase to get fractional ns values.

What is the smallest setting, and desired Step Size ?

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

Would take a while to get cross talk numbers :)

-jg

Il 28/08/2008 22.00, Antonio Pasini ha scritto:

>         // 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]));   


Argh! I stand corrected...

I don't remember exactly what I was drinking last summer when I wrote 
this :-), but it's just plain wrong!

At 180 and 270 degrees obviously one should use inverted clocks or 
properly phase shifted clocks... and then arrange the later stages..

The XAPP225 trick still apply... basically, "distributing" the total 
period budget among a pipeline of four or more FF, to finally align the 
data to the same 1/4 clock.

I "improved" the design starting from the back, and came backwards 
trying not to have more than 0.75T between FF...  wonderful, but wrong.

The line between cleverness and stupidity is so thin :-)

It's amazing how it's easy to find errors when you try to explain your 
work to others!

On Aug 28, 3:11 pm, John_H <newsgr...@johnhandwork.com> wrote:
> On Aug 28, 8:30 am, rickman <gnu...@gmail.com> 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

While the Lattice ECP does not have the SERDES blocks in the I/O,
you can run fairly high data rates with their DDR input flops using
the IDDRX2B "2x geared" primitive.  Only the edge clock has to
run at 1/2 the bit rate (DDR) and the internal clock runs at 1/2
of that speed (1/4 the bit rate) getting 4 bits on every rising edge.

You can see this in the 7:1 serdes reference design (I use this
for Channel-Link at 85 MHz = 595 Mbps).  I should also add
that I use LVDS for these data rates.

Regards,
Gabor

Gabor wrote:
> 
> While the Lattice ECP does not have the SERDES blocks in the I/O,
> you can run fairly high data rates with their DDR input flops using
> the IDDRX2B "2x geared" primitive.  Only the edge clock has to
> run at 1/2 the bit rate (DDR) and the internal clock runs at 1/2
> of that speed (1/4 the bit rate) getting 4 bits on every rising edge.
> 
> You can see this in the 7:1 serdes reference design (I use this
> for Channel-Link at 85 MHz = 595 Mbps).  I should also add
> that I use LVDS for these data rates.
> 
> Regards,
> Gabor

Thanks for that info!  I managed to miss that capability when I went 
through the data sheet.  It may be time for me to reread the info on the 
part I'm now designing with: an ECP2M.

The Lattice I/Os (faster speed grade, of course) are rated at 840 Mb/s 
which would need a clock of only 210 MHz for the IDDR2XB which should be 
quite capable in those devices.

The ECP2 family even has 144 pin tqfp and 208 pin pqfp packages.

That would really be a superb device for this problem.

- John_H

On Aug 29, 9:44 am, John_H <newsgr...@johnhandwork.com> wrote:
> Gabor wrote:
>
> > While the Lattice ECP does not have the SERDES blocks in the I/O,
> > you can run fairly high data rates with their DDR input flops using
> > the IDDRX2B "2x geared" primitive.  Only the edge clock has to
> > run at 1/2 the bit rate (DDR) and the internal clock runs at 1/2
> > of that speed (1/4 the bit rate) getting 4 bits on every rising edge.
>
> > You can see this in the 7:1 serdes reference design (I use this
> > for Channel-Link at 85 MHz = 595 Mbps).  I should also add
> > that I use LVDS for these data rates.
>
> > Regards,
> > Gabor
>
> Thanks for that info!  I managed to miss that capability when I went
> through the data sheet.  It may be time for me to reread the info on the
> part I'm now designing with: an ECP2M.
>
> The Lattice I/Os (faster speed grade, of course) are rated at 840 Mb/s
> which would need a clock of only 210 MHz for the IDDR2XB which should be
> quite capable in those devices.
>
> The ECP2 family even has 144 pin tqfp and 208 pin pqfp packages.
>
> That would really be a superb device for this problem.
>
> - John_H

You may want to watch out for the TQ and PQ packages.  I have had
issues with SSO (ground bounce) using the TQ144 for the 7:1 serdes
unless I carefully controlled output switching.  I have had no
problems
with the 256 BGA parts.  Also be aware of pin noise sensitivity issues
listed in TN1159.  I added a number of virtual grounds to help this.

In article <48B30324.2000603@wustl.edu>, Jon Elson  <elson@wustl.edu> 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.


Why not use time delay vernier chips for this, for example SY604 or AD9501?

-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

On Tue, 26 Aug 2008 15:24:49 -0700, Andrew FPGA wrote:
> I can see how to get to 220MHz, but beyond that I don't
> know. The longest carry chain is 10 bits.
> 

Everybody is assuming an arithmetic counter with carrys, but that
can be worked around. It's possible to implement the counter using
something carry-less and very fast, e.g. a LFSR; the counting is
a little complicated and has to be done offline (effectively it
involves a discrete logarithm calculation, but it's doable for some
LFSRs). I think the original application allows for calculating the 
target count offline.

-- 
		Przemek Klosowski, Ph.D. <przemek.klosowski at gmail>

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
> 

The fabric in V4 will run at 500MHz as long as you don't use the carry 
chains.  The memories and DSP48s are slower, with the -4 speed grade 
capable up to 400 Mhz, but even in that a careful design in the fabric 
has no problem running on a 500 MHz clock.  You'd be better off though, 
bringing the data in and splitting it to a lower clock rate right away. 
You can do that pretty easily using DDR, which while easier in more 
recent devices, can also be done in older devices.