Using FPGA as dual ported ram

[John Adair]

The key here is what latency you can withstand and what size you need. For relatively small requires the internal SRAM of FPGAs like Spartan or Cyclone is fairly fast and cost effective solution. Fot bigger sizes and if you can accept a little more latency FPGA + SRAM/SDRAM/DDR3 is a good solution. We get a lot of people using our Craignell2 -40/48 parts for this as we 256 Mb of SDRAM paired with a Spartan-3A. The 48 pin part allows a FIFO with 16 bit data bus input and with up to 7 control signals and the mirror of that on the output. The 40 pin can still do 16 bit data in/out but you can only support 3 controls signals.

To reduce latency a hybrid structure can be used for a FIFO. This is much more complex but gives the bigger size without losing too much performance on latency. Basically to do this you have an input SRAM in the FPGA and on the way out an output SRAM. Those give the I/O speed. As appropriate blocks of data are moved in/out of the SDRAM in a background operation. Filling(output) or emptying(input) SRAM elements of the FIFO.

One of the nice things you can do in this sort of FIFO that standard parts can't usually do is differing interface sizes. So you might have an 8 bit write with a 32 bit read.

John Adair
Enterpoint Ltd.





On Tuesday, 8 July 2014 15:43:32 UTC+1, 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)



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

 

On Tuesday, July 15, 2014 10:29:57 AM UTC+3, Stef wrote:

In comp.arch.fpga,

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

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.


The algorithm is a non-linear curve fitting algorithm and this will not be
changed (now). I believe this algorithm fits your "inevitably-dependent
inevitably-floating-point operations" case. ;-)

If low risk is highest priority then I can believe in "inevitably-floating-point" part. But "inevitably-dependent" is harder to accept. Most non-linear curve fitting algorithm that I am aware of contain significant degree of inherent parallelism (=multiple dependency chains). The most computationally intensive parts of algorithms often consist of decomposition of symmetric or hermitian matrices, which happens to have better numeric properties than decomposition of arbitrary matrices = can be done with lower precision math.

There may be options for reducing the floating point needs or even convert
to fixed point, but that involves time and risk.

Find the best numeric/algorithms person in the company and allow him to play with your curve fit in Matlab for 2-3 days. That does not sound like a lot of time or risk to me and chances for big improvements w.r.t. to finding more parallelizable and/or requiring lower precision method of computations are very high.

Which can be avoided if
we use a platform that can handle the FP implementation.
--

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

Single tasking: Just Say No.

Single tasking is VERY practical in embedded world in general, even more so in system-on-programmable-chip province. Define hardware interfaces right and you can eliminate most reasons for [preemptive] multitasking. Quite often even interrupts not really needed.


[O.T.]
If low risk is highest priority then shouldn't you use Altera instead of Xilinx?

 

On Tuesday, July 15, 2014 11:56:05 AM UTC+3, Stef wrote:

[O.T.]
If low risk is highest priority then shouldn't you use Altera instead of Xilinx?


Could you explain this remark?

I have used Xilinx in the past (Spartan 3E) and can not remember any issues.

Small chips, small project, small problems.

Also played with Altera at that time and did not really find one better than
the other, just different.

"Playing" is not enough. To get the feeling about buggyness/robustness of tools one has to do (and complete and probably maintain) complex real-world project.

Disclamer: I have no first hand experience with X, so the rest is based on opinions of others.
For non-trivial stuff, among which static timing analysis is the most critical, A tools used to be less buggy than X tools. Easier to express yourself as well. And the whole toolchain in general used to make more sense.
Now, X is in process of major redesign of their suit (Vivado) and what showed up so far makes good impression. But, according to my understanding, the transition to new tools is not completed yet.
And if you are not going to FPGA-only solution then reliability of static timing analysis, esp. of fast interface signals, became a critical part of your project.

 

[Stef]

In comp.arch.fpga,
Tom Gardner <spamjunk@blueyonder.co.uk> wrote:

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.

Their site shows EU stock at the moment. If I'm going to order,
I'll let purchasing handle the ordering system. ;-)

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.

There are a lot of examples for the Zed and microzed, looks ok
indeed. Have not looked into those example however.

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.

Also nice, but for our product, out baseboard with the microzed
plugged on looks like a possible solution.


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

Meade's Maxim:
Always remember that you are absolutely unique, just like everyone else.

 

[Stef]

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

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.

The algorithm is a non-linear curve fitting algorithm and this will not be
changed (now). I believe this algorithm fits your "inevitably-dependent
inevitably-floating-point operations" case. ;-)

There may be options for reducing the floating point needs or even convert
to fixed point, but that involves time and risk. Which can be avoided if
we use a platform that can handle the FP implementation.


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

Single tasking: Just Say No.

 

[Tom Gardner]

On 15/07/14 08:18, Stef wrote:

In comp.arch.fpga,
Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
On 12/07/14 00:33, Stef wrote:
Nice board /when/ it eventually turned up. Avnet's ordering
system was, in my case, peculiarly awful.

Their site shows EU stock at the moment. If I'm going to order,
I'll let purchasing handle the ordering system. ;-)

My experience...
- site showed two lines
- MicroZed 3 weeks wait
- JTAG cable in stock
- I ordered one of each line
- confirmatory email showed same information
- randomly checking by browsing the order next day showed
JTAG cable 4.5 *MONTHS* delay; both delayed until
both available
- /eventually/ managed to contact a human who nominally
cancelled the JTAG cable
- but cancellation did /not/ show on the order page

Unacceptable and unnecessary:
- that flip from "available" to 4.5 months after order
- without notice
- cancellation not indicated

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.

There are a lot of examples for the Zed and microzed, looks ok
indeed. Have not looked into those example however.

The support forums are well attended by Avnet tech staff.

Several minor improvements have been made (now rev F), some
prompted by postings on the forums. Good response.

The support tutorial are helpful, but I've also found
third party tutorials helpful.

 

[Stef]

In comp.arch.fpga,
Tom Gardner <spamjunk@blueyonder.co.uk> wrote:

On 15/07/14 08:18, Stef wrote:
In comp.arch.fpga,
Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
On 12/07/14 00:33, Stef wrote:
Nice board /when/ it eventually turned up. Avnet's ordering
system was, in my case, peculiarly awful.

Their site shows EU stock at the moment. If I'm going to order,
I'll let purchasing handle the ordering system. ;-)

My experience...
- site showed two lines
- MicroZed 3 weeks wait
- JTAG cable in stock
- I ordered one of each line
- confirmatory email showed same information
- randomly checking by browsing the order next day showed
JTAG cable 4.5 *MONTHS* delay; both delayed until
both available
- /eventually/ managed to contact a human who nominally
cancelled the JTAG cable
- but cancellation did /not/ show on the order page

Unacceptable and unnecessary:
- that flip from "available" to 4.5 months after order
- without notice
- cancellation not indicated

Unacceptable indeed. If we want to go in this direction, I'll
talk to the FAE first and get his thoughts about availablity.
Thanks for the warning.

Is the JTAG cable required/recommendend? In a quick read I got
the impression that you could just use a micro SD card.



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

If the facts don't fit the theory, change the facts.
-- Albert Einstein

 

[Tom Gardner]

On 15/07/14 09:31, Stef wrote:

In comp.arch.fpga,
Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
On 15/07/14 08:18, Stef wrote:
In comp.arch.fpga,
Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
On 12/07/14 00:33, Stef wrote:
Nice board /when/ it eventually turned up. Avnet's ordering
system was, in my case, peculiarly awful.

Their site shows EU stock at the moment. If I'm going to order,
I'll let purchasing handle the ordering system. ;-)

My experience...
- site showed two lines
- MicroZed 3 weeks wait
- JTAG cable in stock
- I ordered one of each line
- confirmatory email showed same information
- randomly checking by browsing the order next day showed
JTAG cable 4.5 *MONTHS* delay; both delayed until
both available
- /eventually/ managed to contact a human who nominally
cancelled the JTAG cable
- but cancellation did /not/ show on the order page

Unacceptable and unnecessary:
- that flip from "available" to 4.5 months after order
- without notice
- cancellation not indicated

Unacceptable indeed. If we want to go in this direction, I'll
talk to the FAE first and get his thoughts about availablity.
Thanks for the warning.

I should add: ordered 18th January, MicroZed shipped
1st April, i.e. 11 weeks, not 3.

I suspect that if it is in stock in Europe, then the overall
experience might be better. Ordering from the US is a pain
w.r.t. payment of import duties.

Is the JTAG cable required/recommendend? In a quick read I got
the impression that you could just use a micro SD card.

There are several ways of approaching programming and
debugging the FPGA and ARM. The MicroZed tutorials give a
good introduction. I found that third party tutorials
helped (and slightly hindered) me when starting out with
the (necessarily) complex Xilinx toolset.

For me the SD card would be most useful after the FPGA
hardware is stable. I don't know how many SD card insertions
can occur before something is physically damaged.

Buying
1 x JTAG HS2 Programming Cable (24624) = 51.86EUR
from Trenz Electronics was painless. I also /suspect/ they
have a reasonable long-term availability of their modules,
at a price of course!

 

[Stef]

In comp.arch.fpga,
already5chosen@yahoo.com <already5chosen@yahoo.com> wrote:
> On Tuesday, July 15, 2014 10:29:57 AM UTC+3, Stef wrote:

<snip optimization>

You are probably right that optimizations are possible and I expect that we
will come to that when production numbers are expected to climb high enough.

For now numbers are low and we will have to go with the current algorithm
that was developed and proved over many years. Changing it would not only be
a technical challenge but would also involve a lot of non-technical/political
issues.

This effort can not be justified in this phase of the project.

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

Single tasking: Just Say No.

Single tasking is VERY practical in embedded world in general, even more so in system-on-programmable-chip province. Define hardware interfaces right and you can eliminate most reasons for [preemptive] multitasking. Quite often even interrupts not really needed.

Funny how those random signatures from 'fortune' often seem relevant to the
post. ;-)

If low risk is highest priority then shouldn't you use Altera instead of Xilinx?

Could you explain this remark?

I have used Xilinx in the past (Spartan 3E) and can not remember any issues.
Also played with Altera at that time and did not realy find one better than
the other, just different.


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

.... [concerning quotation marks] even if we *___did* quote anybody in this
business, it probably would be gibberish.
-- Thom McLeod

 

Den tirsdag den 15. juli 2014 10.53.43 UTC+2 skrev Tom Gardner:

On 15/07/14 09:31, Stef wrote:

In comp.arch.fpga,

Tom Gardner <spamjunk@blueyonder.co.uk> wrote:

On 15/07/14 08:18, Stef wrote:

In comp.arch.fpga,

Tom Gardner <spamjunk@blueyonder.co.uk> wrote:

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

Nice board /when/ it eventually turned up. Avnet's ordering

system was, in my case, peculiarly awful.



Their site shows EU stock at the moment. If I'm going to order,

I'll let purchasing handle the ordering system. ;-)



My experience...

- site showed two lines

- MicroZed 3 weeks wait

- JTAG cable in stock

- I ordered one of each line

- confirmatory email showed same information

- randomly checking by browsing the order next day showed

JTAG cable 4.5 *MONTHS* delay; both delayed until

both available

- /eventually/ managed to contact a human who nominally

cancelled the JTAG cable

- but cancellation did /not/ show on the order page



Unacceptable and unnecessary:

- that flip from "available" to 4.5 months after order

- without notice

- cancellation not indicated



Unacceptable indeed. If we want to go in this direction, I'll

talk to the FAE first and get his thoughts about availablity.

Thanks for the warning.



I should add: ordered 18th January, MicroZed shipped

1st April, i.e. 11 weeks, not 3.



I suspect that if it is in stock in Europe, then the overall

experience might be better. Ordering from the US is a pain

w.r.t. payment of import duties.



Is the JTAG cable required/recommendend? In a quick read I got

the impression that you could just use a micro SD card.



There are several ways of approaching programming and

debugging the FPGA and ARM. The MicroZed tutorials give a

good introduction. I found that third party tutorials

helped (and slightly hindered) me when starting out with

the (necessarily) complex Xilinx toolset.



For me the SD card would be most useful after the FPGA

hardware is stable. I don't know how many SD card insertions

can occur before something is physically damaged.

there is no reason to take the sdcard out all the time

if you install a linux you can transfer the configuration file via
ethernet and run stuff in a terminal

you can mount the boot partition so you can also update the kernel and
devicetree without removing the sdcard


-Lasse