Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

How to make CORDIC algorithm calculate the phase of an input vector in a clock cycle?

Status
Not open for further replies.

omara007

Advanced Member level 4
Joined
Jan 6, 2003
Messages
1,237
Helped
50
Reputation
102
Reaction score
16
Trophy points
1,318
Location
Cairo/Egypt
Activity points
9,716
Hi guys ..

Anyone has any information on how to make the CORDIC algorithm calculate say the phase of a certain input vector in one clock cycle ? .. in other words, the current algorithm that I have do implement the calculation process in pipeline stages of many cycles. Effectively it's the CORDIC IP available from OpenCores, that implements the CORDIC on FPGA.

The problem is that this IP effectively targets FPGA and not ASIC as the coding style is obviousely free of RESET's ! .. and moreover, it takes many clock cycles ( 20 ) to calculate the phase of a certain input vector. !! ..

Any hint to how to calculate this phase thing in like one clock cycle ?
 

Re: CORDIC

CORDIC is a iterative algorithum you can't expect answer in just single step
Ofcource you can reduce the no. of eterations by sacrificing accuracy!
Using pipe lining you can get result in per clock! with 20 clks of latency!!!

Other alternative is you multiply ur clk by 20 and use it for CORDIC logic
you will get result in one clock!
 

Re: CORDIC

Yes, the basic idea of the CORDIC algorithm is to calculate a given angle in additions/subtractions of some basic difined angles which corresponds to the arctan of 2's powers. The whole procedure is iterative and u can't expect to be done in one cycle other than by pipelinning where u loose some cycles as latency.

If u want to avoid that latency period u can use look-up tables to store the value of Cos or Sines of ur required angles. It is equally feasible in FPGA or ASIC. It may be some blunt way to solve the problem, but nowadays people r using the technique for it's ease.
 

Re: CORDIC

ani_edaboard said:
If u want to avoid that latency period u can use look-up tables to store the value of Cos or Sines of ur required angles. It is equally feasible in FPGA or ASIC. .

What if the inputs are in rectangular format ? .. even if I had a look-up table, I will need also to divide one input by the other ! .. which is another problem in implementation ! ..

what do you think ?
 

CORDIC

but omara as long as you have stored inputs in LUTs..you can always work on it..did u try using LUTs? as ani said you can surely reduce the latency..

with regards,
arun
 

Re: CORDIC

arunragavan said:
but omara as long as you have stored inputs in LUTs..you can always work on it..did u try using LUTs? as ani said you can surely reduce the latency..

with regards,
arun

LUT that i have is for the arctan(y/x) .. but (y/x) itself has to be calculated ..
 

Re: CORDIC

hi omara..
You didnt mention required clock speed for the CORDIC ARCtan calculation..Also the bitwidth of I/Q values..
If your clock speed is less than 20Mhz and your process is 13u or better .. you can do the arctan calculation in one clock cycle with upto 7 classic cordic iterations(assumiing less than 9 bit I/Q inputs)..

I recently implemented a 6 clock latency Cordic for around 150 MHz in TSMC .13u.. ofcourse if u reduce iterations or reduce operand bitwidths u can make it faster but with lesser accuracy...

another option is to use modified fast cordic algorithms... unfortnuately most of the algorithms proposed cannot be used in Coridc vectoring mode..

2 of the very few papers i found for high speed cordic vectoring mode is attached below.. using fast algorithms increases the area ..still way better than LUT based approach interms of silicon area.

if u are interested in developing hardware based on any of these papers letme know.
 

Re: CORDIC

whizkid said:
hi omara..
You didnt mention required clock speed for the CORDIC ARCtan calculation..Also the bitwidth of I/Q values..
If your clock speed is less than 20Mhz and your process is 13u or better .. you can do the arctan calculation in one clock cycle with upto 7 classic cordic iterations(assumiing less than 9 bit I/Q inputs)..whizkid

The required clock is 8 MHz .. and the process is 13u .. but the I/Q are 16-bits ..

Effectively I want to use the CORDIC core in my communication system receiver in the Frequency Estimation and Correction block .. first to calculate the phase that occurs between 2 consequetive symbols/samples in the receiver .. and second, to correct the phase of all incoming samples ..

Hence, I will use CORDIC in both phase calculation mode and vector rotating mode ..

u mentioned something like the fast algorithm can't work on Vectoring mode .. can u explain more ? ..

Thanks in advance
 

Re: CORDIC

The required clock is 8 MHz .. and the process is 13u .. but the I/Q are 16-bits ..
16 bits !! and 8 MHz ..may be within 2-3 clocks u can do arctan with classic algo.
well I think the I/Q bitwidth is too much.. what is the expected accuracy of result?

u mentioned something like the fast algorithm can't work on Vectoring mode .. can u explain more ? ..
Actually there are 100's of variations of classic cordic algorithm.. many of these variations can be used only in rotation mode. they wont work in vector mode, which is needed for arctan calculation.. the papers i uploaded are the among the very few cordic algos that work for both modes.
 

Re: CORDIC

whizkid said:
The required clock is 8 MHz .. and the process is 13u .. but the I/Q are 16-bits ..
16 bits !! and 8 MHz ..may be within 2-3 clocks u can do arctan with classic algo.
well I think the I/Q bitwidth is too much.. what is the expected accuracy of result?
[whizkid

Why do you think the bandwidth is too much ? .. I am desiging a receiver and the sample width is optional .. I took it as 16-bit (can also be 10-bits according to which ADC i will be using) .. and the base-band works on 8 MHz clock ..

would you please tell me what amazes u first ? .. and second, how can I use the classic algos to do it in 2-3 clocks ?!! ..

by the way .. am currently using the CORDIC core from opencores, which appears to me very primitive as the code is basically written for FPGA and I can't even see an asynchronous reset in the blocks !! ..


P.S. What's the relation between the bandwidth and the sample width ????!!!!!!
 

CORDIC

is any body know where use the CORDIC model most?
it seems this algorithm very useful
 

Re: CORDIC

kelvin_bao said:
is any body know where use the CORDIC model most?
it seems this algorithm very useful

it's mostly used in Frequency Estimation and Correction blocks in Wireless Receivers .. to calculate the phase shift occured between the transmitter and the receiver .. and to correct this phase shift ..
 

Re: CORDIC

kelvin_bao said:
is any body know where use the CORDIC model most?
it seems this algorithm very useful
I use CORDIC rectangular-to-polar conversion in my phased-array beamformer FPGA projects. It converts the complex results to magnitude-phase pairs. I use full pipelining to get one pair of results on each clock cycle.
 

Re: CORDIC

Why do you think the bandwidth is too much ? .. I am desiging a receiver and the sample width is optional
I didnt say bandwidth is high... I said I/Q bit-width (or sample width) is high..

I took it as 16-bit (can also be 10-bits according to which ADC i will be using) .. and the base-band works on 8 MHz clock .. would you please tell me what amazes u first ?
what amazes me is that , how u arrived on this 16 bit sample width(usually selected on basis of required accuracy) ..
Even in very high speed wireless basebands(say UWB . datarate =480Mbits/sec), the accuracy requirement is not so high..

Cordic basically consists of shifters and adders. Adder delay will increase based on bitwidth. which reduces the max frequency or increases the pipeline latency for IQ-> theta conversion.

Also if u use 16 bits. you need 16 cordic iterations to extract the full data(angle).
which again increases your pipeline latency.

and second, how can I use the classic algos to do it in 2-3 clocks ?!! ..
the simplest cordic explanation i ever found is this
https://www.dspguru.com/info/faqs/cordic.htm you can implement RTL based on this.. they also have c-code which u can use to become ore clear.. I implemented RTL based on this C-code.

by the way .. am currently using the CORDIC core from opencores, which appears to me very primitive as the code is basically written for FPGA and I can't even see an asynchronous reset in the blocks !! ..
I also had gone thru opecores cordic core.. i remember it was not so good..

P.S. What's the relation between the bandwidth and the sample width ????!!!!!!
hope u understood that i was not reffereing to bandwidth... i am not sure abt bandwidth samplewidth relation... i guess the Rf-signal amplitude variations will be more for higher samplewidth. which inturn may deteriorate the link quality..


hope it helps
 

Re: CORDIC

CORDIC,what does it mean?
 

Re: CORDIC

oh! yes, who can talk about CORDIC? i don't know it
 

CORDIC

Here's a nice web page of CORDIC info:
**broken link removed**
 

Re: CORDIC

whizkid said:
what amazes me is that , how u arrived on this 16 bit sample width(usually selected on basis of required accuracy) ..
Even in very high speed wireless basebands(say UWB . datarate =480Mbits/sec), the accuracy requirement is not so high..
whizkid

I have designed 802.11a/b/g systems before and we used 16-bit sample as well .. there are no expenses paid against using 16-bit sample if you want to build a highly accurate system ..

in case of my current system, it's a short range wireless system .. effectively a WPAN .. and has a ppm that allows a phase shift between TX and RX of as big as 6*Pi angle or even more .. so, the probability of losing a packet is very high if ur SNR is not relatively high .. so , I'm trying my best to raise any probability of catching accurate data .. even if not relavent to ppm problem ..

anyhow .. i am having everything generic till this moment .. and I can use either 10 or 16 bit sample .. but I don't think i will go for 8 bit ..
 

Re: CORDIC

I have designed 802.11a/b/g systems before and we used 16-bit sample as well .. there are no expenses paid against using 16-bit sample if you want to build a highly accurate system ..
Expenses are Area,Power and pipeline latency etcc.. you can easily see that a 16 bit adder has more delay than an 8bit adder which increases the number of clocks to finish an operation.... moreover as i said earlier 16bits are required only if u intend to do 16 cordic iterations..

in case of my current system, it's a short range wireless system .. effectively a WPAN .. and has a ppm that allows a phase shift between TX and RX of as big as 6*Pi angle or even more .. so, the probability of losing a packet is very high if ur SNR is not relatively high .. so , I'm trying my best to raise any probability of catching accurate data .. even if not relavent to ppm problem ..
if u have a matlab/spw model u can change the bitwidth and check the charateristics..btw which wpan system u r designing?

anyhow .. i am having everything generic till this moment .. and I can use either 10 or 16 bit sample .. but I don't think i will go for 8 bit ..
its a tradeoff.. if u want more acccuracy , u will lose on area and power.. I just enquired my collegue who designed wlan b/g chipset in my company. he said, we used 8bit sample width..

all the best
 

Re: CORDIC

whizkid said:
if u have a matlab/spw model u can change the bitwidth and check the charateristics..btw which wpan system u r designing?
whizkid

I do have a matlab model ... but in maltab we simulate using floating point and I deal with the sample as a complex number ..(I also have a SystemC model) ..

I am with you that the accuracy won't gain great advantage with 16-bit sample , yet as I indicated before, the design is still in the RTL level and the sample width is still generic .. and I prefere to use 16-bit as it's the worst case for the designer ( not for the design ) .. and let's see how big the design will be .. specially that the system is quite simple and it's dramatically below 1-million gate ..

The system is ZigBee by the way ..

P.S. for WLAN .. we used to have 9 PhD System Designers and they all decided to go for a 16-bit samples ..
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top