compilation for 163 bits

[Altera_Forum]

hi to al! 

 the compilation for 163 bits (2 inputs of 163 bits each and the output is also 163 bits) is not exceeding 2% of full compilation and 9% of analysis and synthesis even when the time has crossed 1 hr. i am not able to find out why this occurs as the same code is compiled for 7 bits within 5 mins.could anyone help me in this issue? 

[Altera_Forum]

What's the actual design? If it's parameterized code, I've seen designs that explode in resources. How big is the 7-bits code? What size does it grow to if it's something a little biggger, i.e. 14-bits. (Does it double in size of grow exponentially?)

[Altera_Forum]

The code for 163 bits is the following one: 

 module newconv(c,a,b); parameter N=162;  input [0:N]a,b;  output [0:N]c;  reg [0:N]c;  reg [0:N]d,e;  integer k;  reg y; always @(a or b) begin  d=a;  e=b;    for(k=0;k<N+1;k=k+1)  begin  //$display("d=%b,e=%b",d,e);  y=F(d,e);  c[k]= y;  d=SO(d);  e=SO(e);  end  end        function F; input [0:N]u,v; integer k; integer o,p; begin F=0;  for (k=1; k<652; k=k+1) begin   o=j(k+1);  p=j(k);   F= F^(u[p]&v[o]);  //$display("k=%d, o=%d, p=%d, u=%b, v=%b, f=%b",k,o,p,u[p],v[o],F); end end endfunction     function[0:16]j; input [0:16]k; parameter m=163; parameter T=4; parameter U=149; parameter p=653; reg [0:16]J[0:652];  //integer n,w,m,T,U,p;  integer n,i,l,w;  begin  w=1;  for (l=0; l<T; l=l+1)  begin  n=w;  for (i=0; i<m; i=i+1)  begin  J[n]=i;  n=(2*n)%p; end  w=(U*w)%p; end j=J[k]; end endfunction   function [0:N]SO; input [0:N]SI; reg [0:N] tmp;  begin  tmp = SI;  tmp = tmp<<1;  tmp[N] = SI[0];  SO = tmp; end endfunction endmodule   this the code for 7 bits but with the parameters changed. could u possibly tel me the sol to this compilation prob?

[Altera_Forum]

An iteration scheme in HDL means parallel instantiation of the respective logic, so the below logic is build 652 times, for each function call. 

begin J=i; n=(2*n)%p; end  Of course, part of the calculation reduces to constant expressions, but e.g. n depends on the input data, if I understand correct. I don't expect, that the present code can be synthesized in any existing FPGA.  All working examples, that are dealing with similar numeric problems, are using at least partially sequential processing. As a special point, integer generally means 32 bit. In many cases, the compiler is able to recognize the actual required register size and reduce it respectively, but not always.

[Altera_Forum]

As you have mentioned , that particular loop runs 652 times for each function call.. to be exact..the loop is carried out 163*163*653 times totally. if i want to reduce this constrain, could i go for the case statement where i can assign the values at first itself instead of running the loop for generating the j(n) values??  

secondly, i have made corrections to match the integer size and the array size by changing the size of array to 32.   now also my code is stuck..its running for more than one hour without crossing the 2 % of full compilation.  could there be any other prob?  

[Altera_Forum]

--- Quote Start ---  that particular loop runs 652 times for each function call.. to be exact..the loop is carried out 163*163*653 times totally.   --- Quote End ---   Yes, you're right, it's even worse then I thought, I didn't see the two outer loops. A HDL loop doesn't simply run like a C-Program loop. Each iteration creates new hardware. I simply doesn't work.

[Altera_Forum]

Is there any other way to code for the loop which is iterated many times.. can the parallel looping be done by breaking the loop into a smaller iteration loops.

[Altera_Forum]

there are results for this prog itself stating the total no: of logic elements consumed for a particular device. so there should be some mistake which i am not able to fig out in my code rite? could u tel me whether that loop which runs so many times creates the problem ? 

 another doubt it in the prog, the j[n] get allocated for 652 index and then referencing is made and then that func returns the value. this happens 163*652*163 times. instead if i give a case statement , first itself the reg will be assigned for 652 indexes and only referencing will be made each time the func is called. is this correct or not?

[Altera_Forum]

To run a loop sequentially, that means feeding the same logic with different data, you have to use a clock and some kind of sequencer or state machine. Otherwise, the FPGA compiler is forced to calculate all iterations in parallel, which is impossible due to limited resources.

[Altera_Forum]

I would like to know if the larger 'for' loops are spilt into a number of smaller for loops will that reduce the complexity and resource utilized. Does the function and module concept consumes the same resource.  

 example: for(k=0;k<652;k=k+1) begin F=F+(u[x]*v[y]); end  This loop will be repeated for about 160 times. Kindly explain about this.

[Altera_Forum]

I would like to know whether introducing a clock cycle for each function to bring about sequential operation of the whole module will help in using the resource efficiently.? If so , how will we know what amount of time each function will take as in the above program which has a large for loop

[Altera_Forum]

It has been said, that the inner loop is executed 163*163*653 times (about 17e6), I didn't check in detail. You can translate the code to C and execute it sequentially by a uP, then this number allows to estimate the execution time. It takes a considerable amount of time, but is feasible obviously. The present FPGA code in contrast enforces 17e6 instances of the logic in the innermost loop, it isn't feasible with any existing FPGA. 

 So you may want to find a way to execute a block of the code in parallel and repeat this block sequentially. This is actually often done with problems like the present one, and allows faster solving of complex numerical problems. But the problem has to be analyzed thoroughly for a meaningful solution.  To discuss the problem from a HDL coding view: You can't use a clock in a function. You have to rewrite the code completely to introduce sequential processing.