Over utilization of FPGA resources


I'm currently facing a problem downloading my design to FPGA as my design has overutilized the FPGA resources (slice and DSP48). I'm using FIR compiler_v1 for both my lowpass and notch filter, I understand that my notch filter is probably the cause of the error as it overshot my board's resources (virtex4, xc4vfx12-10ff668). Is there any kind soul who can advise me on ways to reduce the filter resources? Thanks in advance. Below is the summary of the error statement.

best regards, Zhi Qiang

Running delay-based LUT packing... ERROR:Pack:2310 - Too many comps of type "DSP48" found to fit this device. ERROR:Map:115 - The design is too large to fit the device. Please check the Design Summary section to see which resource requirement for your design exceeds the resources available in the device. In particular check the non-slice resources since the slice counts may reflect the early termination of the flow.

Design Summary: Number of errors: 2 Number of warnings: 3 Logic Utilization: Number of Slice Flip Flops: 9,993 out of 10,944 91% Number of SLICEMs: 5,332 out of 2,736 194% (OVERMAPPED) (SLICEMs can only be placed in SLICEM sites.) Number of 4 input LUTs: 2,028 out of 10,944 18% Logic Distribution: Number of occupied Slices: 8,764 out of

5,472 160% (OVERMAPPED) Number of Slices containing only related logic: 8,764 out of 8,764 100% Number of Slices containing unrelated logic: 0 out of 8,764 0% *See NOTES below for an explanation of the effects of unrelated logic Total Number of 4 input LUTs: 7,469 out of 10,944 68% Number used as logic: 2,028 Number used as a route-thru: 109 Number used as Shift registers: 5,332 Number of bonded IOBs: 1 out of 320 1% Number of BUFG/BUFGCTRLs: 3 out of 32 9% Number used as BUFGs: 1 Number used as BUFGCTRLs: 2 Number of FIFO16/RAMB16s: 2 out of 36 5% Number used as FIFO16s: 0 Number used as RAMB16s: 2 Number of DSP48s: 294 out of 32 918% (OVERMAPPED) Number of BSCAN_VIRTEX4s: 1 out of 4 25%
Reply to
Loading thread data ...

If you don't need high speed, you could try to serialize your filter, i.e. one multiply-add per clock. If you need it faster, then split it in larger blocks: for n FIR taps, calculate n/s taps per clock, with s=2, 3, 4, as large as small clk/s could be.

Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

Right. Take a look at

formatting link
to see how it's done!

Also, even though your slices are 100% used, that doesn't mean disaster. The P&R tool spreads the LUTs out over the slices. The LUT count is a more meaniful measure of the 'fullness' of your design.

Lastly, an FIR filter is often not the right solution for a notch filter, especially when the notch width is small compared to Fs/2. It will use an awful lot of resource. Perhaps you could consider an IIR filter for this function? More complex, but smaller footprint.

Cheers, Syms.

Reply to

Someone told me (though I have no experience with it myself) that the older versions of the FIR compiler did not take advantage of symmetry or other potential optimizations, but newer ones do. v1 doesn't sound new...

Ben Jackson AD7GD

Reply to
Ben Jackson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.