Using FPGA as dual ported ram

To interface a fast sampling ADC to a CPU I'm considering to use a fifo or dual ported ram and a small controlling CPLD. Cypress has a nice offering of fifos and dp-rams, but looking at the prices of 512kb density parts I got a bit of a shock: $75 for the fifo and $45 for the dp-ram. That's in single quantity, but they don't go down fast either: $30/1000+ for the dp-ram. :-( (prices from cypress website)

For less money, you can have a Xilinx spartan-6 (XC6SLX9-2TQG144C $20/1+ $14/1000+) with 512kB of Block ram. And you get your controlling 'CPLD' for free. OK you still need a config memory. (prices from avnet website)

Can you just connect one side of the block ram to IO pins and read that from a CPU as if it where a dp-ram? Other side interface would even be simpler as you can keep it internal.

Am I missing something here or is it really that simple? (And yes, I do realize I have to program the FPGA to perform the required function ;-) )

Sample rate is not extremely high (10MSPS), but too fast for the CPU to read on interrupts directly. There may be other options, still investigating.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail) 

One man's constant is another man's variable. 
 Click to see the full signature
Reply to
Stef
Loading thread data ...

You'll find that the CPU memory bus interface and the FPGA BRAM interface don't 100% match up, so you have to put a bit of glue logic (in the FPGA fabric) in the middle, but more yes than no.

It'll be things like, the BRAM is going to be synchronous whereas the memory bus expects to be asynch, so you'll want to latch the membus signals and resynchronize the strobes (CS, WE, OE) to make sure you don't have any glitches, etc. But yeah, you're talking about instantianting a BRAM from the library and throwing a few dozen lines of code around it.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com 
Email address domain is currently out of order.  See above to fix.
Reply to
Rob Gaddi

Hi,

Maybe this helps,an FPGA module with a mid-size Spartan 6 LX 75 device and lots of IOs:

formatting link
Best enjoyed with a JTAG programmer (i.e. Xilinx "USB" JTAG from ebay) as it doesn't support direct FPGA programming via USB, but reprogramming goes through the somewhat slower Flash memory.

AFAIK, also the larger LX 75 can be programmed without paying for a license. A google search "Spartan 6 LX 75 board" shows some boards but I haven't tried any of those.

--------------------------------------- Posted through

formatting link

Reply to
mnentwig

correction: one post on the linked page states that it can now be programmed directly => no need for JTAG.

--------------------------------------- Posted through

formatting link

Reply to
mnentwig

You wrote 512kB which usually means kilobytes. The LX9 has 512 Kb which means kilobits, or 64 kilobytes. If you really needed 512 kilobytes, you would need a much larger part: Spartan 6 LX100, or Artix-7 100T. On the other hand you wrote 512kb when you talked about Cypress parts...

As others have said, the work involved is not a lot and depends on the CPU bus. I suspect that the "small controlling CPLD" code would include pretty much the same logic you'd plug into the FPGA other than the DP RAM.

--
Gabor
Reply to
GaborSzakacs

OK, still need the resync, no direct connect to BRAM. So it will be very similar to a simple I/O register interface that I did years ago in a spartan-3. Thanks for the heads up.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail) 

"Plan to throw one away.  You will anyway." 
 Click to see the full signature
Reply to
Stef

Sorry for the typo, the second should also have been "kb", so the LX9 should be OK.

I wouldn't dare looking up the price of a cypress 512kB FIFO after what I saw on their website earlier today. ;-)

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail) 

Asynchronous inputs are at the root of our race problems. 
 Click to see the full signature
Reply to
Stef

Don't overlook the cost of the power supply regulators to run the FPGA.

It may still be good deal, but maybe just not quite as good...

Andy

Reply to
jonesandy

Good point. I had a quick look and it doesn't seem too bad. I already need a 3.3V and a 1.2V for the CPU so only an additional 2.5V if I need to use LVDS_25. Just need to allow for the extra current draw.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail) 

Pick another fortune cookie.
Reply to
Stef

Just a thought but I use the CPU and it's memory to store the config information. It's not difficult to program a JTAG interface if you have a few spare I/O pins to eliminate config memory.

I'm left wondering if you want a Dual Port RAM, or a FIFO.

They are different beasts but the FIFO would probably be best suited to an FPGA as it uses less pins and the data predictable.

--
Mike Perkins 
Video Solutions Ltd 
 Click to see the full signature
Reply to
Mike Perkins

That is indeed an option I'm considering. It also has the advantage you only have 'one' piece of firmware to update in case of a field update.

Yes they are different, but what actually I need is a buffer. And that can be solved in many ways, including DPRAM and FIFO, they just need different logic and code around them.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail) 

Now I understand the meaning of "THE MOD SQUAD"!
Reply to
Stef

Now, when you are at it, ask yourself the next question: "Do I really need discrete CPU? Will not soft core within FPGA do the job just as well?". Low pin count MCUs with all memories on-chip are often a good idea, but it sounds like your "CPU" is old style monster with parallel external bus. In

2014 using such things is rarely optimal.

The main justification for "CPU" I can think of is when "CPU" gives you on- chip peripherals that can't be implemented in FPGA, like [moderate-speed] A DCs or DACs or Ethernet Phy. But even then, I'd consider using MCU without parallel bus. In such configu ration MCU governs FPGA via medium-speed 20-50 MHz SPI. MCU handle "control plane" processing while FPGA is responsibly for all "data plane" processin g, so high-speed 10 MSPs stream does not need to travel from FPGA to CPU.

Another possibility is using quad-spi flash interface that is present on ma ny of modern MCUs for passing ADC data from FPGA. But to my taste that's to o kludgy.

Reply to
already5chosen

Well it's a 400MHz Cortex A9 with full double precision FPU unit and lots of internal SRAM. Test have shown that this CPU can handle the required algorithm. We also tested a 1GHz Cortex A8 with a 'light' FPU and external SDRAM, this one could not handle the required math.

Is this something you can see an FPGA handle with reasonable developement effort and product cost?

Just today we where checking if an option would be to use no FPGA and connect the ADC through SPI. Proved the normal SPI port was too slow. But then we indeed had a thought about the quad-spi interface. On this CPU it uses a higher clock than the normal SPI and it can handle 1, 2 or

4 bits per clock. But then you would need to convert from ADC SPI to QSPI and have a buffer. So that means we're back to the buffer problem, just with another interface. ;-)
--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail) 

If built in great numbers, motels will be used for nothing but illegal 
 Click to see the full signature
Reply to
Stef

There is a lot we don't know. We don't know the ADC, it's interface or the speed it must run at.

Pins are very expensive, and I do use SPI interfaces wherever possible to reduce pin count so I can use the cheaper, smaller packages for both FPGA and CPUs.

--
Mike Perkins 
Video Solutions Ltd 
 Click to see the full signature
Reply to
Mike Perkins

Sure. Both X and A have SoC FPGAs now that incorporate Cortex A9s on the die. But is it worth the trouble of switching CPUs? Probably not.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com 
Email address domain is currently out of order.  See above to fix.
Reply to
Rob Gaddi

Den onsdag den 9. juli 2014 22.15.04 UTC+2 skrev Stef:

AFAIU you don't need to use 2.5V for LVDS_25 it'll work the same powered by

3.3V, there might be a difference in on chip termination. same for CMOS25@3.3V/CMOS33@2.5V the drive levels will just be slightly higher/lower than configured

-Lasse

Reply to
langwadt

Had a quick look at the Z-7010 (X) and that has dual A9 core, each with VFPv3-D16 FPU (the fast one) and running at 667MHz or more. This is more than adequate for our needs. But it requires external DDR to get enough memory. Price is not too bad either, $55 at Digikey, comparable to the CPU + FPGA solution.

But this thing looks like a huge and complex beast. How hard/easy is it to live with and design for?

What I like about the Renesas RZ (that's the 400MHz A9) is its on die SRAM, so it requires only a QSPI FLASH to boot from and all else is internal. So no DDR busses and the like on the board. Only fast signal on the board is the ADC connection.

Board still needs to be designed, so if we want to switch CPU, now is the time to do it.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail) 

The most disagreeable thing that your worst enemy says to your face does 
 Click to see the full signature
Reply to
Stef

Just found this:

formatting link

Tempting ... Could even uses it as plug in module while volumes are still low. When volumes climb high enough there will be a board re-design anyway.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail) 

I couldn't remember when I had been so disappointed.  Except perhaps the 
 Click to see the full signature
Reply to
Stef

Nice board /when/ it eventually turned up. Avnet's ordering system was, in my case, peculiarly awful.

There does appear to be a reasonable "ecosystem" developing around variants and auxiliary boards, tools and tutorials. You also get a node-locked licence for some of the Xilinx toolset above and beyond their free Vivado/ISE WebPack.

Or there is the "inverse equivalent"...

formatting link
MicroZed? SBC (Single Board Computer) is based on the successful MicroZed SOM (System On Module), with the main difference being the flipped orientation of the I/O expansion connectors. With the I/O connectors on the topside of the board, the MicroZed SBC is designed to accept daughter cards for custom interfaces, making the SBC the main baseboard of a system. This is in contrast to the carrier card approach that is used with MicroZed SOM, where MicroZed plugs into the main baseboard or carrier card. The SBC approach, combined with the lower profile RJ45 Ethernet connector allows MicroZed SBC to serve as a very compact embedded processing system.

Reply to
Tom Gardner

eed discrete CPU? Will not soft core within FPGA do the job just as well?".

it sounds like your "CPU" is old style monster with parallel external bus. In 2014 using such things is rarely optimal.

l

You didn't tell us enough about your algorithm for me to answer. But I'd still try. In general, if an algorithm is of FIR filtering type, then the answer is al most certainly "Yes and with relatively little effort". Even small modern F PGA has a a lot more fix-point arithmetic power than 400 MHz Cortex A9. If the algorithm is of IIR or FFT type then converting it to fix-point will ta ke more understanding and more skilled developer, but still, it almost cert ainly could be done. There are well-know methods of implementing IIR and FF T in fix-point, like doing IIR by means of Lattice-Ladder scheme. The only sort of signal processing algorithms that can't be moved to FPGA i s one that consists of very long chain of inevitably-dependent inevitably-f loating-point operations. I personally never saw such algorithms used in si gnal processing, but they could exist.

Reply to
already5chosen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.