02-27-2008 08:54 PM
hi, i was getting a compile error as below :
Device Utilization Summary:
Number of BUFGMUXs 2 out of 16 12%
Number of External IOBs 242 out of 484 50%
Number of LOCed IOBs 242 out of 242 100%
Number of MULT18X18s 64 out of 96 66%
Number of SLICEs 10761 out of 14336 75%
Clock Rates: (Requested rates are adjusted for jitter and accuracy)
Base clock: 40 MHz Onboard Clock
Requested Rate: 40.408938MHz
Achieved Rate: 33.812342MHz <<<=== Timing Violation
Enclosed vi as below.What could be the reasons for such error ?
And another one is as below with enclosed vi ( error : argument 'or' must have the same length ).
What is the problems ?
Hope you guys can help...thanks a lot.
02-28-2008 03:28 AM
i had modify the code for find_max.vi but it came out :
ERROR:HDLParsers:3367 - "C:/NIFPGA85/srvrTmp/LOCALH~1/FPDE17~1/bushold.vhd" Line 358. 95999 is not included in the index range, 30463 downto 0, of array Clk40WideDataIn.
Any idea what's going on ?
02-28-2008
06:52 PM
- last edited on
05-20-2025
05:39 PM
by
Content Cleaner
Hi Granix,
I took a look at your vi, one thing you must chage on your find_max2.v.
You got an array of size 1500 on the front panel.
Please take a look at this to optimize your code first
What FPGA system are you using? cRIO? RT target?
02-29-2008
03:59 PM
- last edited on
05-20-2025
05:39 PM
by
Content Cleaner
Hi Granix,
The reason your testing.vi is causing Timing Violation is because the execution of your while loop actually takes longer than desired, in this case it is requested to perform at 40MHz but it is truly operating at a maximum rate of 33.8MHz which is slowed down by the longest path of the vi.
To optimize your code to speed up the execution to meet the 40MHz spec try the following:
Fixed point operation: when you multiply fixed points the output of the operator actually allocates more bits to prevent data loss. For example, mulitplying 2 32bit fixed point values would generate a 64 bit fixed point output and the larger the data type, the longer it takes to execute. To prevent this, you can right click on the operator>>properties>>uncheck "adapt to source". Detailed information about fixed point and overflow can be found here.
This is also very good to look at to optimize FGPA code
03-02-2008 01:20 AM
hi Van_L ,
u mean that 1500 elements is over-sized? is it that using handshaking to overcome this problem ? or else any idea ?
10x for helping out.
03-02-2008 07:55 PM
03-03-2008 01:22 PM
03-04-2008
04:03 AM
- last edited on
05-20-2025
05:40 PM
by
Content Cleaner
03-04-2008
12:45 PM
- last edited on
05-20-2025
05:48 PM
by
Content Cleaner
Hi Granix,
To pass data from host to target, change your FIFO type to "Host to Target". You need to check on the FPGA target side of the FIFO is full and check on the host side if the buffer is empty to make sure there's no buffer underflow and overflow issues. Refer to this article with more information about how to write from host. Also refer to Basic DMA Output - R Series.lvproj in the example finder (Help->Find Examples...) for the code to transfer data from host to target.
Regarding the compilation that failure for test.vi, it's due to the fact that the fixed point input for your multiplication operations are too large. Normally, the primative functions (multiplication, add, subtract, etc) should execute in one clock cycle. When it comes to fixed point input and multiplication, however, the output of the multiplication adapts to the size of the input. So if the input is too large, the multiplication operation ends up taking longer than one clock cycle to execute, and cause the compilation to fail timing.
The solution is either reduce the input and output size of the multiplication functions (refer to Van's post to reduce the input and output size of your fixed point multiplication functions). If you do not want to reduce your input and output size (for maximum precision), you can download the Fixed Point Math Library, and use the math library's multiplication function, which allows you to pipeline your multiplication operation and set it to complete in more than 1 clock cycle.
Hope this helps.
Yi Y.
Applications Engineer
National Instruments