Running 24bit adder at 128mhz, which FPGA to choose

I have 16bit data that comes in at 128MS/s, and I want to add 128 of them up at that rate, and then /128 after 128 samples.
Would you please recommend a FPGA or CPLD for that purpose. I don't need many IOs.
But the add performance is important. I would prefer XILINX, cost is important.

A Spartan 6 is more than fast enough. Didn't you look at the data sheet? https://www.xilinx.com/support/documentation/data_sheets/ds162.pdf page 52 has the Fmax for the DSP48A1 as 213 MHz in the lowest speed grade.

You can add the samples as they're coming in, and divide by 128 is just shift right by 7. So I'd say just about any crusty old fpga should do the trick. A cheapo spartan-3 would do the job just fine as would an Altera/Lattice equivalent. If this is the only job the fpga/cpld is going to be doing you can almost pick anything you like.

Since you say you prefer xilinx and want low cost, pick the lowest cost spartan-3 you can find I'd say. And you want to fire up core generator, clickey accumulator, 16-bit input, 24-bit accu, 16-bit output (divided by 128 free of charge), generate core, job done.

Hmmm, you could probably use a Spartan-3A DSP see page 43:https://www.xilinx.com/support/documentation/data_sheets/ds610.pdfFmax of the DSP48A is 250 MHz in the lowest speed grade.

- - - Updated - - -

Looks like you get almost 2x the amount of logic for $2.70 more by going with a S6 instead of the 3A
https://www.digikey.com/product-detail/en/XC3S50A-4TQG144C/122-1541-ND/1756100
https://www.digikey.com/product-detail/en/XC6SLX4-2TQG144C/122-1734-ND/2339857

Heh, I also checked digikey to compare S6 vs S3. Guess it all depends on if there's anything else that needs doing. If all that the OP needs is a single accumulator at that speed then the S3 is already overkill. Something even cheaper from lattice would probably do the trick as well. Or Altera, don't know how that would work out costwise. And I thought the S6/S3 price diff was a bit bigger. 0_o

*recheck*

Yeah, this one in the 100 pin package:
https://www.digikey.com/product-detail/en/XC3S50A-4VQG100C/122-1592-ND/1956974

Anyways, there's also storage of the configuration bitstream to consider. If there's a mcu with enough flash + spi, that might work. Otherwise the non-volatile AN flavor of spartan-3 is another option.

What about a CPLD like coolrunner II? Can it do the job?

FPGA needs a additional prom.

I suspect coolrunner 2 will do the job. Best do a quick test project to be sure.

Regarding fpga needing a prom, like I said thhe spartan-3an does not need an external prom since it has internal flash. The N in that 3an being Nonvolatile.

ahgu said:

I have 16bit data that comes in at 128MS/s, and I want to add 128 of them up at that rate, and then /128 after 128 samples.
Would you please recommend a FPGA or CPLD for that purpose. I don't need many IOs.
But the add performance is important. I would prefer XILINX, cost is important.

Click to expand...

Just a small point, your design would not be running at 128Mhz, it is going to have to run at-least double to catch the clock edge and clock in the sample. ( also is the FPGA/CPLD going to be supplying the clock or are the clocks going to be synchronized?)

There is little chance you can perform the whole operation in 1 clock cycle (at 128Mhz)and be ready for the next input with an external jittery clock ( you are going to need to be stable for at least 1 clk cycle to get the data in. and 1 cycle to perform the addition, otherwise as you are doing the addition the value will be changing in one of the operands.

Also what is your precision?, because 128 16 bit values will come out to about 7FFFFF , so you will need a 24 bit adder

As for dividing it…..don't bother!!!

When you wire up the soft logic, just wire up the bits so that the low order bits are truncated and top order are zero filled.

I.E bit 0 is only bit 0 in your head, it could quite as easily be bit 7 internally to the FPGA/CPLD and bit 0 externally.

Just a small point, your design would not be running at 128Mhz, it is going to have to run at-least double to catch the clock edge and clock in the sample. ( also is the FPGA/CPLD going to be supplying the clock or are the clocks going to be synchronized?)

There is little chance you can perform the whole operation in 1 clock cycle (at 128Mhz)and be ready for the next input with an external jittery clock ( you are going to need to be stable for at least 1 clk cycle to get the data in. and 1 cycle to perform the addition, otherwise as you are doing the addition the value will be changing in one of the operands.

Click to expand...

Just idle speculation, I fear. I would expect a design running synchronous with the sample clock for the time being.

Running a 24 bit accumulator at 128 MHz isn't demanding for recent FPGAs. Single cycle isn't particularly a problem because you still have a pipelining option.

The design can be also described as first order CIC decimator.

The clock to the ADC will be provided by the FPGA/CPLD. about 128Mhz sampling rate. That is another reason to go with FPGA since it has the PLL. If I use CPLD, I have to provide a external clock. But I doubt the CPLD will do the job anyway.

FPGA/CPLD gives 128MHZ clock to ADC, ADC send out parallel 16bit data to FPGA/CPLD, FPGA/CPLD does add/divide, and send 16bit data out at 1MHZ using SPI.

ahgu said:

?.. would prefer XILINX, cost is important.

Click to expand...

Just curious , what is you budget? €1000? €100? €3?

I count less than 100 4-input LUT logic elements (Cyclone III or MAX II, other vendors should give similar results). Plus the SPI serializer.

Why are you using a fast ADC, do you actually need the digital boxcar averager? Alternatively an 1 MBPS ADC with respective analog filter could be used, even an analog averager if exactly required.

You mean an analog LPF, cannot because the signal is not continuous, it comes in steps, the length of the steps is much shorter than the RC time.

FvM said:

I count less than 100 4-input LUT logic elements (Cyclone III or MAX II, other vendors should give similar results). Plus the SPI serializer.

Why are you using a fast ADC, do you actually need the digital boxcar averager? Alternatively an 1 MBPS ADC with respective analog filter could be used, even an analog averager if exactly required.

Click to expand...

You mean an analog LPF, cannot because the signal is not continuous, it comes in steps, the length of the steps is much shorter than the RC time.

Click to expand...

Makes no sense so far. The shorter the input signal, the better it will be averaged by a low-pass-filter.

Can you give a typical input waveform and tell which signal parameters are exactly extracted in signal processing?

A special point might be that you want to keep exactly the signal area (true average). Of course this is neither guaranteed by a 128 MSPS ADC, but it may be easier to achieve with a simple low-pass. It's the ratio of sampling rate to filter time constant that determines the maximum averaging error for an arbitrary input signal. It can be made very small by using a sufficient low filter cut-off frequency. Or completely cancelled by using an analog boxcar averager.

FvM said:

Just idle speculation, I fear. I would expect a design running synchronous with the sample clock for the time being.

Running a 24 bit accumulator at 128 MHz isn't demanding for recent FPGAs. Single cycle isn't particularly a problem because you still have a pipelining option.

The design can be also described as first order CIC decimator.

Click to expand...

Idle speculation? Hardly.

If his clock had not been provided by the FPGA ( which at the stage I wrote the above, he had not clarified), then just how are you going to syncronise the FPGA clock with the ADC clock and read the results in the same clock domain?

You are either running in a clocked logic or not, ( clocked or combinatorial), for clocked processes you would need to syncronise the two clock domains. ( FPGA & ADC)

a simple example.
https://www.doulos.com/knowhow/fpga/synchronisation/

code_slave said:

If his clock had not been provided by the FPGA ( which at the stage I wrote the above, he had not clarified), then just how are you going to syncronise the FPGA clock with the ADC clock and read the results in the same clock domain?

Click to expand...

How so? Take as an example the case where the clock is provided externally. You then connect this external clock to an fpga clock input of your choice, and drive one of the dedicated internal clock nets. This fpga clock net is now synchronous with the external clock. To keep the example simple lets assume no excessive board delays so no problems with skew. If there would be too much skew you'd need some extra clock management, but the case will be essentially the same.

Anyways, you have an internal clock net that is synchronous with the external ADC clock. And then you simply clock your input buffer flip-flops with THAT clock. No need to synchronize between different clock domains, because those flip-flops and the external ADC are inside the same clock domain by design. And you run the 24-bit accumulator inside that very same clock domain at 128 MHz. And then every 128th cycle within that 128 MHZ clock domain you have a valid average value.

You are either running in a clocked logic or not, ( clocked or combinatorial), for clocked processes you would need to syncronise the two clock domains. ( FPGA & ADC)

Click to expand...

And in this case you are running a clocked process, and you are staying within the same clock domain. Just because you cross the fpga device boundary doesn't suddenly make it a different clock domain. You will have delays etc to deal with yes, but fpga's have clock management resources for that.


And now back to the OP:
Are you sure you want to use the fpga as the clock source for a 16-bit ADC running at 128 MHz? FPGAs are not really known for their low jitter. That jitter is not great for your ADC effective number of bits. See for example this one: http://cds.linear.com/docs/en/design-note/dn1013f.pdf

That and can you give an example of your signal, because like FvM I don't follow your statement regarding the LPF and the discontinuities of your input signal.