FPGA compile time error with SCTL

[guilio_2008]

I am atempting to speed up my program with SCTL.  However, it seems if I put a SCTL in the program, put my FXP added, subtract, divide, etc...inside that loop, compile the software, I get my therortical time< the 40MHz.  I can't post my code up here due to constraints I have, but wanted to see if anyone knows why this happens?  I thought it would speed it up.  To give a brief description, I have a 9215 inside a while loop, and a SCTL inside the while loop.  inside the SCTL, i have my normal math function and boolean cases.  Compile the software,, then I get my theor. time error.  I also have other loops in the software structured as a producer consumer loops using FIFO to transfer data.  This is how increase the therortical speed the first time, but I don't want to have to use another FIFO to another loop.  Any ideas?

guilio_2008

[Eli_S]

Hi Guilio,

The reason why you are getting this error is because the code you have inside the SCTL does not fit. What this means is that the code cannot all execute in a single cycle but rather needs more than one cycle to complete execution. A common way to solve this problem is to pipeline the code using shift registers. Another thing you can do is create a derived clock that runs slower than the main 40MHz clock and time the SCTL from this slower clock.

[guilio_2008]

I tried to pipeline the program and I still got the same results.  What worries me most is this is just half of the program.  I got to create an exact replica in the same VI.  So far I reduced the data type to the lowest possible for fxp.  Now I have this question.  Should I use the fxp math functions such as add, subtract, etc...or should I use the standard math functions?  Would this increase the speed?

I have a producer consumer loop setup and had to create another loop cause I felt that the last part of my math function was slowing the loop down too much but now I'm running into issues where a fxp division block doesn't want to update the number as inputs are being streamed in.  Any clues to this?  When I stop that loop, it updates, when I start the program, it grabs a number and freezes. 

Thanks,

guilio

[kikiduu]

Hi Guilio,

I can't comment on why the SCTL is not allowing your code to get compiled, without actually seeing the logic that you are trying to implement. But, if your aim is to increase the processing speed of your logic, you don't need SCTL. SCTL is used to reduce the number of FPGA slices that are used. You may use SCTL if you run out of slices.

BTW have you tried to compile he code without SCTL and is it working?

[guilio_2008]

It works on and off.  There are times that my theortical clock is like 45 or 48, other times the TC is 40.46 (barely faster), and other times it's below.  Depends on the changes I make.  Sometimes the smallest change such has reducing the date type of one block can make a big difference in the TC, and how long it compiles.  Right now I'm putting all the math back into the oringinal producer comsumer loop and see if reducing bits of the fxp number helps the TC where it will at least run.  I'll just have to refine from there when I include another copy of the program in the same VI.  I have a good feeling that most of this problem is lack of knowledge on my side cause I just dove in and started using this.  I'll see if I can post a JPG of the program and hide the name so people can look at it and determine what may be the problem.

[Eli_S]

I suggest you use regular while loops instead of SCTL to see if you can get it to compile like that first. If that works then you can start switching back to SCTL to see where the problem is happening. I also mentioned before using derived clocks. Have you tried that?

[guilio_2008]

Haven't used derived clocks.

Well, I scaled back some of the fixed point bit size, however, I still get a variable clock speed from barely over the 40MHz clock to 45 MHz.  It's not consistant at all.

Also, how can I adjust the bit size to give me the MIN that I need.  Right now I am manually going in and changed the numbers, but sometimes what should be the min I need ends up not work.  Also, in some of the FXP math functions, it mentions overflow.  I don't need large bit size so I reduce the size, and then it says overflow may occur.  Would this cause any problems?

Thanks,

guilio

[guilio_2008]

I have scaled back the fxp numbers, and even copied the code and pasted it over just to see if it will compile and to my surprise, it did.  The TC went from ~40-~45.  I still need to add another module in the program so hopefully this doesn't cause problems and hopefully I don't need to add anything else.  Just wondering, why does the theoretical clock jump around so much?  It's seems that the smallest change does this.

guilio

[Eli_S]

Are you getting this TC values from the compilation report? These values do change slightly everytime you compile. So the solution was to reduce the size of the fixed-point numbers?