Don't know about pre built blocks.By the way, if you have low number of input bit you can just store the function values in a Look Up Table. How many input bits you have?
With 18bits a LUT is no feasible.There are many options on the literature. One is Cordic as previosuly reported. Another option is a mix of ROM and linear (or quadratic interpolation). Unfortunately it is not a simple task and a good approximation requires a careful analysis of the literature. My group published many papers on these topics. As example: 1) direct digital frequency synthesizers with polynomial hyperfolding technique (http://www.alteraforum.com/search/srchabstract.jsp?tp=&arnumber=1315881&querytext%3dde+caro%26refine...) De Caro, D.; Napoli, E.; Strollo, A.G.M.; circuits and systems ii: express briefs, ieee transactions on (http://www.alteraforum.com/forum/../xpl/recentissue.jsp?punumber=8920) Volume: 51 , issue: 7 (http://www.alteraforum.com/forum/../xpl/tocresult.jsp?isnumber=29164) Digital Object Identifier: 10.1109/tcsii.2004.829553 (http://dx.doi.org/10.1109/tcsii.2004.829553) Publication Year: 2004 , Page(s): 337 - 344 IEEE Journals 2) high-performance special function unit for programmable 3-d graphics processors (http://www.alteraforum.com/search/srchabstract.jsp?tp=&arnumber=4694047&querytext%3dde+caro%26refine...) De Caro, D.; Petra, N.; Strollo, A.; circuits and systems i: regular papers, ieee transactions on (http://www.alteraforum.com/forum/../xpl/recentissue.jsp?punumber=8919) Volume: 56 , issue: 9 (http://www.alteraforum.com/forum/../xpl/tocresult.jsp?isnumber=5230335) Digital Object Identifier: 10.1109/tcsi.2008.2010150 (http://dx.doi.org/10.1109/tcsi.2008.2010150) Publication Year: 2009 , Page(s): 1968 - 1978
thanks a lot. but your links can not fonud. may be this can be a result of my browser.so can I ask one more question? have you any idea aboul kalman filter design with verilog ?
The links cannot work.You've to search on IEEExplore website but you can download the papers only if your institution pays the IEEE. With reference to Kalman... sorry, it's not my expertise. I can't help.
Those links effectively do not work.If you search for the titles on the web you will find them at IEEE, so you need access rights ($$$). Cordic is a proven approach, well documented on the web (free) and in fact a simple algorithm. Back in 2004 I made my own specific implementation in AHDL. I recompiled it today for 10 and 16 bits precision (16 bits is the maximum I projected at the time), if I extrapolate the LC usage an 18 bit cordic would use about 1150 LC (Cyclone I) and run at about 250 MHz in pipelined mode. Making it combinatorial will use about the same amount of LCs but will be a lot slower( est. 70 ns delay). I used a Cyclone EP1C4F324C6 device for the test compilations.
--- Quote Start --- You've to search on IEEExplore website but you can download the papers only if your institution pays the IEEE. --- Quote End --- I don't think that people that work for organizations that can afford the IEEE fees come to this forum (or any other) to seek help. (They will have access to adequate resources and experience in-house ...) I propose to add a rule to the forum rules that all papers quoted must be freely accessible. Who will be putting $35,- (or so) down for an article you don't know whether it will help?
Universities pay the fee.I come from an University and come to this forum to exchange ideas with people experts in the field. I can assure you that in the Universities not everybody is an expert on Altera FPGA design. As a consequence web resources and forums are very much used to improve the quality of the work. Further, I think that many University people, such as young master thesis students, come to this forums to seek advices for their projects. These students usually have access to many on-line journals such as IEEE.
I don't want to start a polemic here (I sincerely hope I didn't).A lot of people visiting this forum are not at a university or working in a large(r) company, yet are very experienced and have solved real-life projects. I think it is a matter of politeness that if you bring an argument into a discussion that other parties can explore that argument and eventually learn from it.
Another way is to directly use the math libraries that your HDL supports. Usually this already comes with Quartus. For example, in VHDL you could simply add the math_real library, and call arctan(). Probably the Cordic method provides better/faster results, but I guess this is the simplest way if you just want to add an arctan function.
use ieee.math_real.all; ... variable x:real:=0.0; variable n:integer:=0; ... /* some manipulation on x */ ... n:=integer(arctan(x));
i just checked, actually the VHDL math_real library already implements Cordic. If you're using VHDL, you can put your mind at rest with the arctan() method. I'm not too sure with other HDL languages though.
The arctan() function in the library expects a real as input where Angela specified 18 bits, which I presume to be a std_logic_vector or a constrained integer type.Second, if the compiler will synthesize the library function, we end up with combinatorial implementation which may be too slow. But the library function can do double duty: first serve as a guidance into Cordic and second to use in the testbench.
--- Quote Start --- The arctan() function in the library expects a real as input where Angela specified 18 bits... --- Quote End --- Yes, you have a point. Maybe we can do some conversion to real first? --- Quote Start --- Second, if the compiler will synthesize the library function, we end up with combinatorial implementation which may be too slow. But the library function can do double duty: first serve as a guidance into Cordic and second to use in the testbench. --- Quote End --- I think Quartus should be able to synthesise the library function, since I looked the arctan() function up in the math_real.vhd IEEE package inside the Quartus distribution. But not too sure on how fast this algorithm is going to be. Probably, we can study the CORDIC() function inside the same file to see if it will be fast enough?
The real type is only supported by Quartus (and other vendors synthesis tools) for simulation and compile time caculations, e.g. generation of look-up tables or constant initialization. It's not synthesizable. As ieee.math_real exclusively contains operation with the real type, it's not suited for synthesis as well.
FvM was quicker than me to state that the type real is not synthesizable. (I needed to check first ...)Any function described by a for loop will ultimately end up being combinatorial (and thus usually too slow), pipelining to speed it up is however plain manual labor. New VHDL constructs to make this easier would be very interesting -> System-VHDL?
Yes, that was why I recasted the result back to integer, a synthesizable type. I agree that real itself isn't synthesizable, but it's allowed for calculations. I assumed a real input to go into the arctan() function, but if it's a std_logic_vector, we need some kind of conversion to real first.The arctan() function just serves as the calculation, where it will give a real result (which isn't synthesizable). But we can re-cast this result to integer (or others) that would make it synthesizable?
Unfortunately casting won't help. The actual operand presented to the synthesis would still be a real, which is not synthesizable.Writing an integer equivalent for the arctan() function as given in the ieee_math_real is not that difficult. I'll might give it a shot later tonight (after finishing my other work duties).
cool... tell us about it. :)I just tried the arctan() function, and Quartus compiles without errors. I believe Quartus should throw an error if something if not synthesizable right? Or at least a warning? I saw (in RTL Viewer) that some logic was generated from this (mostly muxes), but have not done P&R nor verified it working on a board yet. Here, I assigned a bunch of output ports directly to "integer". There's a catch when using this method though. Your input to arctan() should be a "constant real", means not something that can be varied during runtime. The code I submitted previously assumes that x is a constant and doesn't change during runtime (which is unlikely). Does anyone know of a workaround for this (Quartus can't synthesize non-constant reals)?
--- Quote Start --- Writing an integer equivalent for the arctan() function as given in the ieee_math_real is not that difficult. --- Quote End --- Thinking about this again, and the fact that Quartus only synthesizes real during "compile time" to generate LUTs and doesn't support varying reals during runtime, I think yes, writing an integer equivalent of arctan() would be the way to go. Do post it up when it's ready... :) Probably they might just include it in the next revision of VHDL. ;)