Welcome
Username or Email:

Password:


Missing Code




[ ]
[ ]
Online
  • Guests: 17
  • Members: 0
  • Newest Member: omjtest
  • Most ever online: 396
    Guests: 396, Members: 0 on 12 Jan : 12:51
Members Birthdays:
All today's birthdays', congrats!
ramses (16)
Arcstarter (31)
Zak (15)


Next birthdays
05/12 Colin 99 (53)
05/14 hvguy (41)
05/14 thehappyelectron (14)
Contact
If you need assistance, please send an email to forum at 4hv dot org. To ensure your email is not marked as spam, please include the phrase "4hv help" in the subject line. You can also find assistance via IRC, at irc.shadowworld.net, room #hvcomm.
Support 4hv.org!
Donate:
4hv.org is hosted on a dedicated server. Unfortunately, this server costs and we rely on the help of site members to keep 4hv.org running. Please consider donating. We will place your name on the thanks list and you'll be helping to keep 4hv.org alive and free for everyone. Members whose names appear in red bold have donated recently. Green bold denotes those who have recently donated to keep the server carbon neutral.


Special Thanks To:
  • Aaron Holmes
  • Aaron Wheeler
  • Adam Horden
  • Alan Scrimgeour
  • Andre
  • Andrew Haynes
  • Anonymous000
  • asabase
  • Austin Weil
  • barney
  • Barry
  • Bert Hickman
  • Bill Kukowski
  • Blitzorn
  • Brandon Paradelas
  • Bruce Bowling
  • BubeeMike
  • Byong Park
  • Cesiumsponge
  • Chris F.
  • Chris Hooper
  • Corey Worthington
  • Derek Woodroffe
  • Dalus
  • Dan Strother
  • Daniel Davis
  • Daniel Uhrenholt
  • datasheetarchive
  • Dave Billington
  • Dave Marshall
  • David F.
  • Dennis Rogers
  • drelectrix
  • Dr. John Gudenas
  • Dr. Spark
  • E.TexasTesla
  • eastvoltresearch
  • Eirik Taylor
  • Erik Dyakov
  • Erlend^SE
  • Finn Hammer
  • Firebug24k
  • GalliumMan
  • Gary Peterson
  • George Slade
  • GhostNull
  • Gordon Mcknight
  • Graham Armitage
  • Grant
  • GreySoul
  • Henry H
  • IamSmooth
  • In memory of Leo Powning
  • Jacob Cash
  • James Howells
  • James Pawson
  • Jeff Greenfield
  • Jeff Thomas
  • Jesse Frost
  • Jim Mitchell
  • jlr134
  • Joe Mastroianni
  • John Forcina
  • John Oberg
  • John Willcutt
  • Jon Newcomb
  • klugesmith
  • Leslie Wright
  • Lutz Hoffman
  • Mads Barnkob
  • Martin King
  • Mats Karlsson
  • Matt Gibson
  • Matthew Guidry
  • mbd
  • Michael D'Angelo
  • Mikkel
  • mileswaldron
  • mister_rf
  • Neil Foster
  • Nick de Smith
  • Nick Soroka
  • nicklenorp
  • Nik
  • Norman Stanley
  • Patrick Coleman
  • Paul Brodie
  • Paul Jordan
  • Paul Montgomery
  • Ped
  • Peter Krogen
  • Peter Terren
  • PhilGood
  • Richard Feldman
  • Robert Bush
  • Royce Bailey
  • Scott Fusare
  • Scott Newman
  • smiffy
  • Stella
  • Steven Busic
  • Steve Conner
  • Steve Jones
  • Steve Ward
  • Sulaiman
  • Thomas Coyle
  • Thomas A. Wallace
  • Thomas W
  • Timo
  • Torch
  • Ulf Jonsson
  • vasil
  • Vaxian
  • vladi mazzilli
  • wastehl
  • Weston
  • William Kim
  • William N.
  • William Stehl
  • Wesley Venis
The aforementioned have contributed financially to the continuing triumph of 4hv.org. They are deserving of my most heartfelt thanks.
Forums
4hv.org :: Forums :: Computer Science
« Previous topic | Next topic »   

Complex math inside Altera Cyclone FPGA

Move Thread LAN_403
Adrenaline
Tue Jul 30 2013, 10:20PM
Adrenaline Registered Member #235 Joined: Wed Feb 22 2006, 04:59PM
Location:
Posts: 80
You really didn't answer my questions. If you have a 16bit ADC, it should/can be integer. Why not just perform all your calculations in integer or fixed point? Floating point seems like an unrequired complexity especially in FPGA as already noted.
Back to top
Linas
Wed Jul 31 2013, 07:04AM
Linas Registered Member #1143 Joined: Sun Nov 25 2007, 04:55PM
Location: Vilnius, Lithuania
Posts: 721
Steve Conner wrote ...

So you got the ADSP to boot? smile

Yes, spend some time reading and found mistake in booting, also i writed data MSBF format, but adsp need LSBF.

Adrenaline wrote ...

You really didn't answer my questions. If you have a 16bit ADC, it should/can be integer. Why not just perform all your calculations in integer or fixed point? Floating point seems like an unrequired complexity especially in FPGA as already noted.

I really don't know what will be, if i use long signed integers to do the math. What i do is single point DFT, when i have real and imag part of frequency, i can calculate phase with atan2 function. Maybe it is possible to make it by using signed integers, i will try to model this and see if that will not degrade performance and accuracy, but from DSP point of view, native variable is f32,
If some one knows theory of information, what bit depth coefficients (in bits, like do i can only use 12b and have same resolution in phase calculation, or i need 32 or even 64 ?) will not degrade performance ?

Or better question, if i have 128 point of signal, lats say 4 periods of sinus, and it's 16b depth, what is the phase resolution of this system ?
Back to top
Steve Conner
Wed Jul 31 2013, 08:58AM
Steve Conner Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706
Well done! I hate troubleshooting these types of issues. tongue

To a first approximation, the phase resolution would be 4/128 of 360 degrees, or 11.25 degrees. It is dominated by the small number of points, because you can only figure out the phase to the nearest sample.

You can use interpolation to get a more accurate result. This amounts to converting the excess amplitude resolution into phase resolution. This implies that the result will only be as good as the SNR of the input signal, because amplitude noise gets converted into phase noise.

Running the algorithm several times and averaging the result will help with SNR, at the cost of lowering the control loop bandwidth.

In a related project, we use an 8192 point FFT feeding a frequency estimation algorithm which provides the frequency for an 8192 sample "single point DFT". We can measure the phase of a 50Hz signal, sampled at 5kS/s and 12 bits, to within 0.01 degree.

To do this on a FPGA, my first thought would be a large lookup table of the sine and inverse tan functions, but that could cause problems with division by zero. And indeed division itself, which you want to avoid in a FPGA.

If processing time permitted I would use the "lock-in" method where I run the correlation over and over again, using a successive approximation algorithm to vary the phase until I find the phase that makes the imaginary component of the output zero. This gets rid of the inverse tan lookup table and the division issues, by getting the correlation to solve itself. Only a sin/cos lookup table and MACs are required.

This technique worked nicely for me (in fixed-point arithmetic with a 16x16 multiply and 40-bit accumulator) in a lock-in detector algorithm that I wrote for a gas analyser. If the phase doesn't vary too much between runs, you can speed it up by using the solution from last time as an initial guess. If you take this to its logical conclusion you have a digital PLL that "solves" the phase by locking to it. I've also used this method.

Maybe in a FPGA you could run the correlation in parallel for several different test phase values, and then interpolate the actual value from the outputs of this "phase filter bank". This technique could be mixed with successive approximation to achieve the best trade-off between speed and amount of FPGA fabric used. At the next iteration, the phase filter bank would be reloaded with test phase values spaced more closely around the answer from the previous one.

The Spartan 3A-DSP has about 100 hardware MAC blocks that can clock at 250MHz, so you could maybe calculate 20 or 50 test phase values at once.
Back to top
Linas
Wed Jul 31 2013, 09:56AM
Linas Registered Member #1143 Joined: Sun Nov 25 2007, 04:55PM
Location: Vilnius, Lithuania
Posts: 721
I like DFT, because it is bruteforced way to get phase at the same time i finish read detector. i don't have any problems with division by zero because of simple trick to at very very small value to imaginary part, and division by zero should be rare anyway.
Link2

About ADC resolution, i don't find any point of go lower that 16b, since it's same bus width , and noise in LSB will give same effect as no noise in 12b conversion.

Also will fractional table will give me better phase precision ? because i can calculate 6.5 (i usually go for 6 or 7 point in frequency domain) frequency coefficients for phase measurements.

Running phase matching algorithm will not work, because phase can be pretty random, so it will add complexity with no speed benefit in my mind.

Altera cyclone 4 have 30x 9bit multiplier blocks and they can run on same speed +-

Also FPGA can do between 2 to 4 readout averaging (ADC running 2x or even 4x speed of detector) that could give from 1.414 to 2x better readout SNR.

Just wondering, knowing situation what you would do differently ? (sine i am no good in electronics, my approach is bruteforce)

Also is it possible ( i think not ) to get not 2pi tracking ability, but more that that like 6pi or more ?
Back to top
Dr. Slack
Mon Aug 12 2013, 07:13AM
Dr. Slack Registered Member #72 Joined: Thu Feb 09 2006, 08:29AM
Location: UK St. Albans
Posts: 1659
Single point DFT, yes, fixed point math, yes, but anything involving division to get the phase, no.

Look up COORDIC. It's a very flexible algorithm designed for doing conversion either way between cartesian and polar, and is suited to running in fixed point with no multipliers, only adds and subtracts. If you need performance, it can run pipelined and bang out one conversion per clock cycle. If you want chip area, it can compute one bit of the answer per clock cycle with three adders, or one bit per three cycles with one adder.

It's a nice tool to have in your FPGA DSP tool-box, because running theta -> XY, it can replace the trig lookup table in an NCO, and a demodulation mixer for free, and with a tiny bit of modification it can find reciprocals or square roots as well.

As far as interpolation goes, doing an FFT gives you bit growth. Half of that bit growth is true noise-reducing extra resolution. Think of it as spreading the total noise power over the nyquist bandwidth, and suffering only the noise in one bin. So if you have (say) a 10 bit ENOB ADC, and do a 256 point DFT, the resulting phase estimate will have a 14 bit ENOB, which gives you a noise-limited resolution of the order of 2^-14 radians.
Back to top

Moderator(s): Chris Russell, Noelle, Alex, Tesladownunder, Dave Marshall, Dave Billington, Bjørn, Steve Conner, Wolfram, Kizmo, Mads Barnkob

Go to:

Powered by e107 Forum System
 
Legal Information
This site is powered by e107, which is released under the GNU GPL License. All work on this site, except where otherwise noted, is licensed under a Creative Commons Attribution-ShareAlike 2.5 License. By submitting any information to this site, you agree that anything submitted will be so licensed. Please read our Disclaimer and Policies page for information on your rights and responsibilities regarding this site.