|
From: fmostafa on 25 Jun 2008 12:01 On Jun 25, 4:44 pm, austin <aus...(a)xilinx.com> wrote: > fmostafa, > > Which family? > > In V5, we have an added bit in the bitstream which prevents LUTRAM and > SRL16/32 from being readback. The function performed is called GLUTMASK > (not that it matters what it is called). It was added just so you do > not have to deal with "knowing" which LUT are not to be disturbed (by a > readback/verify). > > Austin hi, thanks for your fast replay, but my family is virtex 2 pro, is there a solution based on constrains.
From: fmostafa on 25 Jun 2008 12:03 On Jun 25, 4:44 pm, austin <aus...(a)xilinx.com> wrote: > fmostafa, > > Which family? > > In V5, we have an added bit in the bitstream which prevents LUTRAM and > SRL16/32 from being readback. The function performed is called GLUTMASK > (not that it matters what it is called). It was added just so you do > not have to deal with "knowing" which LUT are not to be disturbed (by a > readback/verify). > > Austin hi, thanks for your fast replay, but my family is virtex 2 pro is there a solution
From: austin on 25 Jun 2008 12:17 fmostafa, In Virtex 2 Pro, you would need to apply placement constraints to place the LUTRAM/SRL16 all in the same column so you could avoid that column later in a readback. http://toolbox.xilinx.com/docsan/xilinx4/data/docs/cgd/types3.html Such constraints may make the design so it can not be routed. It is not a simple process, and one that would require a lot of manual floor planning, and trial and error. That is why we added the GLUTMASK feature. Austin
|
Pages: 1 Prev: RAM and shift register constraints Next: FPGA area use by module? |