Low Pin Count FPGA/CPLD for FIFO+bits

--- Quote Start ---

1. data input to device is at 80Msps.. 3 lots plus external Clock.

--- Quote End ---

"3 lots"? 3 channels?

How many bits is each 80Msps data stream, eg., (8-bits plus clock) x 3 channels = 24-bits input + 3 input clocks

What logic levels? 2.5V LVCMOS, LVDS, CML, etc?

--- Quote Start ---

2. data is all mashed up, so needs untangling, then FIFOing... ideally 24bits wide by 10, more if possible.

--- Quote End ---

Mashed up in what way? If its just the ordering of bits that is weird, an FPGA does not care. If the data is XOR modulated or 8/10B encoded, then the FPGA can decode.

Why a FIFO? Do you want the data output in a single clock domain? If so, are the three input clocks phase-locked, but arbitrarily skewed?

--- Quote Start ---

3. data then needs extracting on a parallel interface, 12 databits wide, plus a few control bits.

--- Quote End ---

"Extracting" in what way?

Cheers,

Dave

--- Quote Start ---

"3 lots"? 3 channels?

How many bits is each 80Msps data stream, eg., (8-bits plus clock) x 3 channels = 24-bits input + 3 input clocks

--- Quote End ---

4 wires: 80MHz clock, 3x 80Msps datastreams, datastream1 = 4MSBs of channelA, then 4MSBs of channelB. datastream2 = 4MediumSBs of channelA, then 4MediumSBs of channelB. datastream3 = 4LSBs of channelA, then 4LSBs of channelB, having clocked out 8bits on each datastream the whole thing repeats. There is no 'latch' all timing is dead reckoned off a starting pattern. (yuk)

--- Quote Start ---

What logic levels? 2.5V LVCMOS, LVDS, CML, etc?

--- Quote End ---

1.8V CMOS. (I believe.. silicon is still in development but nealy done)

--- Quote Start ---

Mashed up in what way? If its just the ordering of bits that is weird, an FPGA does not care. If the data is XOR modulated or 8/10B encoded, then the FPGA can decode.

--- Quote End ---

not xored etc. I know the FPGA shouldn't care but it will need sorting out inside the FPGA as the kit that follows does care.

--- Quote Start ---

Why a FIFO? Do you want the data output in a single clock domain? If so, are the three input clocks phase-locked, but arbitrarily skewed?

--- Quote End ---

The problem is the tester clock that the data has to be aligned too is not good enough to drive the RF, so we are forced to have two asynchronous clocks, they are almost phase locked, so even with thousands of samples we shouldn't get even one clock cycle drift. Trouble is "shouldn't" isn't "doesn't" and we can't afford to assume we won't get a problem... not if it risks bakcing up 10s of thousands of product chips.

--- Quote Start ---

"Extracting" in what way?

--- Quote End ---

The tester needs to be 'bus master' in whatever interface we have between the CPLD/FPGA and the tester. I'm envisioning a 12bit wide databus plus a few control lines, running at 20Msps.

--- Quote Start ---

Cheers,

Dave

--- Quote End ---

thanks

Mike

--- Quote Start ---

4 wires: 80MHz clock, 3x 80Msps datastreams, datastream1 = 4MSBs of channelA, then 4MSBs of channelB. datastream2 = 4MediumSBs of channelA, then 4MediumSBs of channelB. datastream3 = 4LSBs of channelA, then 4LSBs of channelB, having clocked out 8bits on each datastream the whole thing repeats. There is no 'latch' all timing is dead reckoned off a starting pattern. (yuk)

--- Quote End ---

Ok, this sounds straightforward enough. The implementation will require a finite state machine (FSM); it will synchronize to the start pattern and then demultiplex data using counters.

If all three data streams use the same clock, then one FSM can be used. If not, then separate FSMs are required.

--- Quote Start ---

1.8V CMOS. (I believe.. silicon is still in development but nealy done)

--- Quote End ---

This is no problem for either a CPLD or FPGA.

--- Quote Start ---

The problem is the tester clock that the data has to be aligned too is not good enough to drive the RF, so we are forced to have two asynchronous clocks, they are almost phase locked, so even with thousands of samples we shouldn't get even one clock cycle drift. Trouble is "shouldn't" isn't "doesn't" and we can't afford to assume we won't get a problem... not if it risks bakcing up 10s of thousands of product chips.

--- Quote End ---

What do you mean by almost phase-locked? If the tester clock is phase-locked, but just has excessive jitter, then the system is still synchronous.

The key parameters in your selection between a CPLD vs an FPGA are;

* CPLDs do not have RAM blocks, so implementing FIFOs is expensive (uses lots of logic cells).

* FPGAs have more flexible clocking options and include PLLs.

I'd recommend starting by looking at the Cyclone IV series of FPGAs. Just select the biggest in a TQFP, and make sure you connect the ground pad when you create custom board.

80Msps is not too fast. I think you could do some prototyping with a Terasic DE0-nano pretty effectively (they're $80).

--- Quote Start ---

The tester needs to be 'bus master' in whatever interface we have between the CPLD/FPGA and the tester. I'm envisioning a 12bit wide databus plus a few control lines, running at 20Msps.

--- Quote End ---

What does the "tester" need to communicate to the FPGA? Is it the tester that needs to communicate, or a control PC? If its a control PC, then its pretty easy to interface an FTDI FT232H USB-to-FIFO device and achieve 40MB/s data rates. The USB interface programming is as simply as using a COM port (or /dev/ttyUSB0 if you're a Linux guy).

Cheers,

Dave

--- Quote Start ---

What do you mean by almost phase-locked? If the tester clock is phase-locked, but just has excessive jitter, then the system is still synchronous.

--- Quote End ---

The two clocks are not synchronised, but are guarenteed to be very very close in frequency, such that a pre-cal to ascertain the phase offset will allow the two to run in phase for a reasonable length of time without phase slip (a few milli seconds at least, which is enough).. the biggest problem will not be drift, but low frequency phase jitter, and that's what worries me.

The 'tester' is like nothing what normally sits on a bench, we're using an LTX Cedance Diamond series tester.

All these sorts of testers demand to be 'clock master' to anything they are testing, but their clocks are not RF-capable and they cannot accept an external clock, so we need to cope with two very slowly drifting clocks, so the chip will be locked to an RF-clean clock not the tester clock, but the tester will still want to be 'clock master'. A FIFO gives us a solution whereby we need no guesswork.. it should 'just work'...:rolleyes:

Anyway, many thanks for your time and effort.

--- Quote Start ---

The two clocks are not synchronised, but are guarenteed to be very very close in frequency, such that a pre-cal to ascertain the phase offset will allow the two to run in phase for a reasonable length of time without phase slip (a few milli seconds at least, which is enough).. the biggest problem will not be drift, but low frequency phase jitter, and that's what worries me.

The 'tester' is like nothing what normally sits on a bench, we're using an LTX Cedance Diamond series tester.

All these sorts of testers demand to be 'clock master' to anything they are testing, but their clocks are not RF-capable and they cannot accept an external clock, so we need to cope with two very slowly drifting clocks, so the chip will be locked to an RF-clean clock not the tester clock, but the tester will still want to be 'clock master'. A FIFO gives us a solution whereby we need no guesswork.. it should 'just work'...:rolleyes:

Anyway, many thanks for your time and effort.

--- Quote End ---

Ok, thanks for the explanation. A FIFO-based solution will meet your requirements. The FIFO full/empty signals can be monitored to catch any excessive phase drifts. Look at the Cyclone IV series devices.

Cheers,

Dave