Using FPGA as dual ported ram - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Using FPGA as dual ported ram
In comp.arch.fpga,
Quoted text here. Click to load it

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.
We've slightly trimmed the long signature. Click to see the full one.
Re: Using FPGA as dual ported ram
On 15/07/14 09:31, Stef wrote:
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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!



Re: Using FPGA as dual ported ram
Den tirsdag den 15. juli 2014 10.53.43 UTC+2 skrev Tom Gardner:
Quoted text here. Click to load it

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


Re: Using FPGA as dual ported ram
On Friday, July 11, 2014 4:27:49 PM UTC+3, Stef wrote:
Quoted text here. Click to load it
eed discrete CPU? Will not soft core within FPGA do the job just as well?".
Quoted text here. Click to load it
 it sounds like your "CPU" is old style monster with parallel external bus.
 In 2014 using such things is rarely optimal.
Quoted text here. Click to load it
l  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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.

Re: Using FPGA as dual ported ram
In comp.arch.fpga,
Quoted text here. Click to load it

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.

Re: Using FPGA as dual ported ram
On Tuesday, July 15, 2014 10:29:57 AM UTC+3, Stef wrote:
Quoted text here. Click to load it
y need discrete CPU? Will not soft core within FPGA do the job just as well
?".
Quoted text here. Click to load it
but it sounds like your "CPU" is old style monster with parallel external b
us. In 2014 using such things is rarely optimal.
Quoted text here. Click to load it
ots
d
rnal  
Quoted text here. Click to load it
ent  
Quoted text here. Click to load it
s almost certainly "Yes and with relatively little effort". Even small mode
rn 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 wil
l take more understanding and more skilled developer, but still, it almost  
certainly could be done. There are well-know methods of implementing IIR an
d FFT in fix-point, like doing IIR by means of Lattice-Ladder scheme.
Quoted text here. Click to load it
GA is one that consists of very long chain of inevitably-dependent inevitab
ly-floating-point operations. I personally never saw such algorithms used i
n signal processing, but they could exist.
Quoted text here. Click to load it
e  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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

Quoted text here. Click to load it
t  
Quoted text here. Click to load it

Find the best numeric/algorithms person in the company and allow him to pla
y with your curve fit in Matlab for 2-3 days. That does not sound like a lo
t 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.

Quoted text here. Click to load it
 mail)  
Quoted text here. Click to load it

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 oft
en even interrupts not really needed.


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

Re: Using FPGA as dual ported ram
In comp.arch.fpga,
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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


Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Using FPGA as dual ported ram
On Tuesday, July 15, 2014 11:56:05 AM UTC+3, Stef wrote:
Quoted text here. Click to load it

Small chips, small project, small problems.

Quoted text here. Click to load it

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

Re: Using FPGA as dual ported ram
On 11/07/2014 09:26, snipped-for-privacy@yahoo.com wrote:
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Using FPGA as dual ported ram
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 Cyclon
e is fairly fast and cost effective solution. Fot bigger sizes and if you c
an 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 1
6 bit data bus input and with up to 7 control signals and the mirror of tha
t on the output. The 40 pin can still do 16 bit data in/out but you can onl
y support 3 controls signals.

To reduce latency a hybrid structure can be used for a FIFO. This is much m
ore complex but gives the bigger size without losing too much performance o
n latency. Basically to do this you have an input SRAM in the FPGA and on t
he 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(ou
tput) 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 w
rite with a 32 bit read.

John Adair
Enterpoint Ltd.


  


On Tuesday, 8 July 2014 15:43:32 UTC+1, Stef  wrote:
Quoted text here. Click to load it
 mail)
Quoted text here. Click to load it


Site Timeline