Using FPGA as dual ported ram

[Stef]

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.
-- A.J. Perlis

 

[Rob Gaddi]

On Tue, 08 Jul 2014 16:43:32 +0200
Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:

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

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.

 

[mnentwig]

Hi,

Maybe this helps,an FPGA module with a mid-size Spartan 6 LX 75 device an
lots of IOs:
http://numato.com/saturn-spartan-6-fpga-development-board-with-ddr-sdram
Best enjoyed with a JTAG programmer (i.e. Xilinx "USB" JTAG from ebay) a
it doesn't support direct FPGA programming via USB, but reprogramming goe
through the somewhat slower Flash memory.

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



---------------------------------------
Posted through http://www.FPGARelated.com

 

[mnentwig]

>> Best enjoyed with a JTAG programmer
correction: one post on the linked page states that it can now b
programmed directly => no need for JTAG.


---------------------------------------
Posted through http://www.FPGARelated.com

 

[GaborSzakacs]

Stef wrote:

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)

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...

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.

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

 

[Stef]

In comp.arch.fpga,
Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:

On Tue, 08 Jul 2014 16:43:32 +0200
Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:


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


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.

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."
- Fred Brooks, "The Mythical Man Month"

 

[Stef]

In comp.arch.fpga,
GaborSzakacs <gabor@alacron.com> wrote:

Stef wrote:
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)

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...

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.
-- D. Winker and F. Prosser

 

On Tuesday, July 8, 2014 4:36:34 PM UTC-5, Stef wrote:
> I wouldn't dare looking up the price of a cypress 512kB FIFO after what I saw on their website earlier today. ;-)

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

 

[Stef]

In comp.arch.fpga,
jonesandy@comcast.net <jonesandy@comcast.net> wrote:

On Tuesday, July 8, 2014 4:36:34 PM UTC-5, Stef wrote:
I wouldn't dare looking up the price of a cypress 512kB FIFO after what I saw on their website earlier today. ;-)

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...

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.

 

[Mike Perkins]

On 08/07/2014 15:43, Stef wrote:

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)

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.

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.

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
www.videosolutions.ltd.uk

 

[Stef]

In comp.arch.fpga,
Mike Perkins <spam@spam.com> wrote:

On 08/07/2014 15:43, Stef wrote:
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)

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.

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.

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.

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.

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"!

 

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] ADCs or DACs or Ethernet Phy.
But even then, I'd consider using MCU without parallel bus. In such configuration MCU governs FPGA via medium-speed 20-50 MHz SPI. MCU handle "control plane" processing while FPGA is responsibly for all "data plane" processing, 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 many of modern MCUs for passing ADC data from FPGA. But to my taste that's too kludgy.

 

[Stef]

In comp.arch.fpga,
already5chosen@yahoo.com <already5chosen@yahoo.com> wrote:

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.

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?

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] ADCs or DACs or Ethernet Phy.
But even then, I'd consider using MCU without parallel bus. In such configuration MCU governs FPGA via medium-speed 20-50 MHz SPI. MCU handle "control plane" processing while FPGA is responsibly for all "data plane" processing, 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 many of modern MCUs for passing ADC data from FPGA. But to my taste that's too kludgy.

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
purposes.
-- J. Edgar Hoover

 

[Mike Perkins]

On 11/07/2014 09:26, already5chosen@yahoo.com wrote:

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] ADCs or DACs or Ethernet Phy. But even then, I'd
consider using MCU without parallel bus. In such configuration MCU
governs FPGA via medium-speed 20-50 MHz SPI. MCU handle "control
plane" processing while FPGA is responsibly for all "data plane"
processing, 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 many of modern MCUs for passing ADC data from FPGA. But to my
taste that's too kludgy.

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
www.videosolutions.ltd.uk

 

[Rob Gaddi]

On Fri, 11 Jul 2014 15:27:49 +0200
Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:

In comp.arch.fpga,
already5chosen@yahoo.com <already5chosen@yahoo.com> wrote:
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.

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?

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.

 

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

In comp.arch.fpga,

jonesandy@comcast.net <jonesandy@comcast.net> wrote:

On Tuesday, July 8, 2014 4:36:34 PM UTC-5, Stef wrote:

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



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...



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.

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

 

[Stef]

In comp.arch.fpga,
Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:

On Fri, 11 Jul 2014 15:27:49 +0200
Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:

In comp.arch.fpga,
already5chosen@yahoo.com <already5chosen@yahoo.com> wrote:
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.

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?


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.

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
not approach what your best friends say behind your back.
-- Alfred De Musset

 

[Stef]

In comp.arch.fpga,
Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:

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?

Just found this: http://www.zedboard.org/product/microzed

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
time I found out that M&Ms really DO melt in your hand.
-- Peter Oakley

 

[Tom Gardner]

On 12/07/14 00:33, Stef wrote:

In comp.arch.fpga,
Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:

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?

Just found this: http://www.zedboard.org/product/microzed

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.

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"...
http://www.zedboard.org/product/microzed-sbc
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.

 

On Friday, July 11, 2014 4:27:49 PM UTC+3, Stef wrote:

In comp.arch.fpga,

already5chosen@yahoo.com <already5chosen@yahoo.com> wrote:

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.



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?

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 almost certainly "Yes and with relatively little effort". Even small modern FPGA 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 take more understanding and more skilled developer, but still, it almost certainly could be done. There are well-know methods of implementing IIR and FFT 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 is one that consists of very long chain of inevitably-dependent inevitably-floating-point operations. I personally never saw such algorithms used in signal processing, but they could exist.