Hi Glenn, Even though timing is not critical, we have a lot of data to load, and loading dual port BRAMs seems to be too slow. The timing ignore sounds promising. We'll check it out. Thanks.
Regards, Dale Sent from my iPhone On Mar 5, 2012, at 4:15 PM, "G Jones" <[email protected]<mailto:[email protected]>> wrote: Hi Nimish, If the time required to load the coefficients is not critical, you could consider using explicit dual port BRAMs with one fo the ports connected to a shared register for data and a shared register for address. This may give you more control in meeting timing. We've also been experimenting with adding TIG (timing ignore) statements to the timing constraint file so that things like shared registers are not constrained to meet timing, since it shouldn't make much difference. This is not yet commonly done though. Glenn On Mon, Mar 5, 2012 at 12:38 PM, Nimish Sane <[email protected]<mailto:[email protected]>> wrote: Hi all, We are using multiple "shared bram" yellow blocks in our FX correlator design (ska-sa software library, Xilinx 11.4 tools, Linux, Roach 2, KatADC, 150MHz FPGA clock — eventually 300 MHz). We want to store some gain/scaling and other coefficients in this memory and read from the memory during run-time. These blocks utilize around 50% of BRAM resources on Roach 2. I cannot get rid of timing errors with the shared bram blocks. I have tried various configurations of shared bram blocks. The closest I have got is when I broke the library link of these yellow blocks and changed bram implementation to optimize speed instead of area. Still, few (3) small timing errors persist. Are there any specific things to keep in mind while using this block? Does anyone have any experience or suggestions to share? Thanks, Nimish
