Recommend FPGA for pattern generator

[AlexI]

I'm looking at building a board that pairs a fast DAC with a FPGA to drive it.  This is for instrumentation use, something like the Red Pitaya but much faster.  I'll probably open source the design when done.

The FPGA stores patterns  (in local memory only, no external memory) and plays them out when a trigger signal comes in.  I'd like an FPGA that can drive at least 28 LVDS outputs at 600Mhz clock with DDR (1200Mbit per LVDS pair, LVDS_25).  Which FPGA should I use?

I've confirmed with Xilinx that Artix 7 (eg XC7A15T) can do this in some speed grades.  I'd like to at least consider Altera and Lattice, but I'm not familiar enough with them to tell which parts I should ne looking at. Older Xilinx eg Spartan 6 may be an option too.

This needs IO only, but with pretty demanding timing.  No data processing, and a few kb of distributed memory.

Can you recommend a part/family for this?

I'm looking for easy to develop/good examples for this kind of application,  and cheapest.

[AlexI]

@cleaningOut I agree Artix seems like overkill.  Spartan 6 is limited to 1050Mbit/s on SERDES outputs though; I checked.
 That wold limit the DAC speed. I may be willing to live with that, but I was wondering what other options there are outside Xilinx.  Something like a fast IO-optimized FPGA with not many gates.

[asmi]

Spartan-7's are slowly appearing on the market, which seem like a perfect choice for your application.

But I agree with cleaningOut - implement design first to see how much gates you will actually need. I've almost got burned by this once when I designed the board for certain part, and later it turned out that this part is too small to fit my design. Good thing I've decided to do an actual P&R before I ordered the PCB.
This is one thing which is better to overestimate than to underestimate. Especially so for first revision as you will probably want to use things like ILA for debugging - and it requires extra FPGA resources.

[NorthGuy]

Without external memory, you will need to use at least some of the internal memory to store the patterns, or you will need to somehow generate the patterns. This will take BRAM and fabric. The transmission itself will not take much. Therefore, to evaluate the size of the FPGA you need, start by designing the part which generates/stores patters.

If you also need communications, such as Ethernet or USB, this will take more logic and some BRAM, you need to account for this.

Xilinx pins are in banks of 50. If you need one 14-bit 2.5 Gs/s DAC channel serialized 1:2 (as I infer from 28 LVDS you posted) you'll need 56 pins (plus pins for the clock). This will not fit into one bank, but will fit into two. Your will have to spend some effort controlling skew between BUFIO clocks in these two banks to 100-200 ps (or whatever your DAC can handle). You may want to consider using only 11 bits to fit all pins into a single bank.

[asmi]

Xilinx pins are in banks of 50. If you need one 14-bit 2.5 Gs/s DAC channel serialized 1:2 (as I infer from 28 LVDS you posted) you'll need 56 pins (plus pins for the clock).

ISERDES can only do 1:4 deserialization in DDR mode (also 6,8, and 10, 14 when cascaded).
Then there is a question of what you going to do with such huge data rate. Artix fabric is not very quick and trying to run logic at 200+ MHz is going to be challenging. The only way I see this working is using FIFO to further parallelize data into very wide bus, but that's going to require wide memory bus. Zynq HP port is only 64bit wide.

[AlexI]

@asmi Thanks, that's interesting!

I'm interfacing to a DAC, not an ADC.  Might be a bit easier - instead of having a ton of data to process or store, I just need to repeat the same pattern to the output.  Patterns are short, usually 1000 points or so (maybe 5k-10k points max).

Is there a similar limit for OSERDES in DDR mode only doing 4:1?

I hear you about wide bus... what is the effective total throughput to BRAM?  Can I use distributed (LUT) RAM?

[asmi]

@asmi Thanks, that's interesting!

I'm interfacing to a DAC, not an ADC.  Might be a bit easier - instead of having a ton of data to process or store, I just need to repeat the same pattern to the output.  Patterns are short, usually 1000 points or so (maybe 5k-10k points max).

Sorry I confused your topic with another one that's going on here

Is there a similar limit for OSERDES in DDR mode only doing 4:1?

No, OSERDES in DDR mode can do 2,4,6, 8, as well as 10 or 14 when cascaded. But there still is a question of where the data comes from at such rate.

I hear you about wide bus... what is the effective total throughput to BRAM?  Can I use distributed (LUT) RAM?

For middle speed grade (-2) maximum frequency of FIFO is 460 MHz, so in 2:1 serialization it gives 920 Mbps per pin pair. Highest speed grade has 509 MHz max FIFO frequency, but it's very expensive and hard to find in stock. If you want to achieve higher rate, you will need to use higher order of serialization. This will also make achieving timing closure easier because clock frequency will be lower.
For BRAM, it can be configured in 4k x 2, 2k x 9, 1k x 18 or 512 x 36 mode for "half BRAM" (18Kb), or 8k x 4, 4k x 9, 2k x 18, 1k x 36 or 512 x 72 mode for a full module (36Kb). So if you use x72 config and run it at max frequency, you can get 72 x 460 = 33120 Mbps. But again, I'm almost certain you won't be able to feed it from any logic at 460 MHz, so the max burst is only 512 transfers.

If you want to go faster, you have a couple of choices:
1. First of all, if you have a freedom to choose a DAC, you may want to prefer the one that has serial JESD204 interface as Artix's MGTs support that interface.
2. Alternatively, you can opt to use Kintex-based Zynqs (Z030 and above), they have significantly faster fabric, but they are quite expensive.

[NorthGuy]

what is the effective total throughput to BRAM?  Can I use distributed (LUT) RAM?

BRAM can do 400-500MHz depending on the speed grade. for 10k samples x 14-bit you only need 140k of memory.

Distributed RAM is not any faster and it is only 64-bit deep. If you need higher depth, you will need to use muxes, which slows the things down considerably.

Your DDR input clock is about 600 MHz, then you can do 1:2 (this version is called ODDR, not OSERDES), but then you need to produce data at 600 MHz, which is tricky. 1:4 OSERDES will let you go at 300 MHz, or 1:8 will give you 150 MHz. 300 MHz is the way to go. But, even with 1:8, your bus is not too wide - 28 x 8 = 224 bit. If you read it from BRAM then only 4 BRAM blocks will give you wide enough bus. 7 BRAM blocks (configured as 1024x32) will give you enough RAM to store 16k samples. Since they're really 36-bit wide each, you can even use the rest of the bits for control signals.

[AlexI]

@asmi Thanks!

About JESD204, could you tell me your thoughts about the pros and cons of that?

In particular, how much easier / harder is it to implement in a low-cost FPGA?

I looked at it, and it seems that (everything else being equal) the DACs that support it are more expensive, and the FPGAs that support it are much more expensive.  I couldn't find a lot of single channel JESD204 DACs with similar specs; they mostly tend to be two channel, and priced to match, but I don't need two channel.  The pros seem to be that switching between DACs would be easier if using JESD, and there is an upgrade path to *much* faster DACs.

[AlexI]

@asmi About BRAM: I think I follow all that, but I have some (probably very newbie) questions:

Can I use multiple 36k blocks?  Perhaps even one block per OSERDES?

Can I cascade blocks to make a wider bus?

[hamster_nz]

@asmi About BRAM: I think I follow all that, but I have some (probably very newbie) questions:

Can I use multiple 36k blocks?  Perhaps even one block per OSERDES?

Can I cascade blocks to make a wider bus?

Yes and yes.

One of the problems you can face is the fanout of the address lines to lots of memory blocks. The other is fan-in of the data from memory blocks to an output.

Adding pipelining and/or a few extra cycles of latency between the memories and I/O pins can help this, as it lets the tools insert extra registers as needed to meet timing.

And sometimes in cases like this it is worth using low-level primatives, to ensure you get exactly what you want, not what the tool chain thinks you want, which is often a balanced result,like (power, area, performance).

It is also worth trying a few different options for width/depth ratios, as the one will give a more natural.fit for placement and efficient routing.

[NorthGuy]

Can I use multiple 36k blocks?  Perhaps even one block per OSERDES?
Can I cascade blocks to make a wider bus?

You can even use several blocks per bit if you want. They can be cascaded to create 65,536 depth, and you can mux them for even higher depth, which will give you longer data series.

The width of one BRAM block can be 72 bits, but you can use any amount of BRAM blocks in parallel, which will give you an ability to use more DACs, if needed.

The most important think is to make sure that your FPGA of choice has enough BRAM blocks to cover all your needs.