C to FPGA Tools (Impulse C and others) and necessary trig IP

Hi Pete, There's a guy here on CAF who's something to do with FpgaC.

Perhaps you could ask him to help implement the COS function, he seems to be at a loose end! ;-)

Back in the real world, I think you're gonna have to code this in an HDL. I suggest doing some research on CORDIC algorithms. Alternatively, For SIN/COS you might consider the Sunderland algorithm and the sine-phase difference algorithm. For square roots, I like this:-

HTH. Cheers, Syms.

Often, for sin and cos you can get by with a lookup table. Depending on how much accuracy you actually need your lookup table may not even need to be all that large, especially since you only need from 0 to 90 degrees in the table.

Phil

Yep, the algorithms I mentioned dramatically reduce the size of the lookup table for a given accuracy. Cheers, Syms.

Actually it would be a fun project, and down the line of where we are headed long term anyway. The FpgaC project has a way to go to be fully featured, but it seems that this project could be done as a series of user written functions with little trouble.

As far as being a loose end, I'll take that as a complement :) Life is very disappointing when you sit around a wait for things to happen. Stirring things up a little is sometimes required to shake the cobwebs off that are holding everyone stuck in place.

I think you are taking the wrong approach. I'm sure you can get the C code running. But in reality if you have to implement sin/cos & sqrts, then the C code will be far from optimal, and you might need a vertex to do the job of a Spartan

Simon

Actually, I find it not that different in many cases from similar VHDL/Verilog and have the advantage of being able to tweek the output in FpgaC when I don't like it. Especially when I do a boolean design, it goes right thru FpgaC as boolean logic equations to the LUT. The C may look a bit ugly that way, but you certainly have nearly exact control over the output. For example:

[jbass@fastbox tests]$ cat example1.c int a:1,b:1,c:1; #pragma inputport (a,a9) #pragma inputport (b,a10)

int sum_of_products:1; #pragma outputport (sum_of_products,a11)

main() {

c = (sum_of_products = (a&b) + c); }

produces:

[jbass@fastbox tests]$ fpgac -target cnf example1.c [jbass@fastbox tests]$ cat example1.cnf _example1_Running^CLK = VCC; _a^CLK = port(_a,"a9"); _b^CLK = port(_b,"a10"); _c^(CLK*_example1_main__state_C1) = (~_c*_b*_a)+(_c*~_a)+(_c*~_b); port(_sum_of_products,"a11")^(CLK*_example1_main__state_C1) = (~_c*_b*_a)+(_c*~_a)+(_c*~_b); _example1_main__state_C1 = ~_example1_Running;

which in xnf/edif is a bit more verbose (so I'll just take the meat of it):

SYM, _sum_of_products-OBUF, OBUF PIN, I, I, _sum_of_products PIN, O, O, sum_of_products END EXT, sum_of_products, O,, LOC=_a11 SYM, FFin-_sum_of_products, EQN, EQN=((~I0*I1*I2)+(I0*~I2)+(I0*~I1)) PIN, I2, I, _a PIN, I1, I, _b PIN, I0, I, _c PIN, O, O, FFin-_sum_of_products END SYM, _sum_of_products, DFF PIN, D, I, FFin-_sum_of_products PIN, C, I, CLK PIN, CE, I, _example1_main__state_C1 PIN, Q, O, _sum_of_products END

This is also true.. but that is NOT what a C programmer calls C code ;-) If you are going to write Boolean equations in C then you might as well use one of the "official" languages as others can help. my two cents :-)

Simon

P.S. I didn't see any sin functions :-)

code

the

job

Sorry ... but the arithmetic functions in every synthesis tool are reduced to the boolean equations too ... FpgaC included. My point is that C based HLL's, or even the HLL versions of them, can do just as good a job at both the boolean's and the arithmetics, as you will see in VHDL doing arithmetics.

Nope .... but didn't you get the point that better arithmetics are on the list of development projects for FpgaC? And that working with someone to implement them in a useful way would just add to the value of FpgaC?