"Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag news:2zybf.3489$IC.2133@dukeread07...> GaLaKtIkUs� wrote: > >>But why were these changes done ? is it a sacrifice made by Xilinx to >>allow adding XtremeDSP and other hard cores inside the Virtex-4 ? >>Or is it simply because a few people use the CLBs as memory or shift >>registers? >> > Its because of the users Xilinx polled, most either didn't use SRL16's at > all or if they did used less than 5% of the LUTs as SRL16s/RAM. The SRL16 > is not free, it substantially increases the physical area occupied by the > LUT, as well as the testing required to verify the part 100%, so Xilinx > took the opportunity to reduce the complexity by stripping out half the > distributed memory elements. I think a large part of the fault lies in the > fact that Xilinx does a very poor job of touting the benefits of the SRL16 > capability, in fact, I don't think they have more than a few people there > that understand how powerful this element is. It is a shame they stripped > it out of half the part, and I think it makes the software that much > harder as well. They don't really feel the pain though because their top > shelf users are not really using the capability effectively, and synthesis > only makes use of it in the most rudimentary way. > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com http://www.andraka.comAGREE 100% SRL16 is way useful but I do not see it nearly possible that they will be used the best way with regular synthesis. so the customer should be at least aware of what is needed to get the SRL16 being used (automatically) or then use them directly. Antti
Anybody understand this ISE 7.1 error, and what to do about it???
Started by ●November 4, 2005
Reply by ●November 7, 20052005-11-07
Reply by ●November 7, 20052005-11-07
Antti Lukats wrote:>AGREE 100% > >SRL16 is way useful but I do not see it nearly possible that they will be >used the best >way with regular synthesis. so the customer should be at least aware of what >is needed >to get the SRL16 being used (automatically) or then use them directly. > >Antti > > >Current synthesis pretty much only instantiates the SRL16 as a fixed length shift register, and then only if the designer didn't put resets on the registers. There is supposedly a magic incantation in Synplicity that will infer a dynamic shift, but for th elife of me I have not been able to get it to infer that consistently, and the words to the incantation seem to change with each revision of the software. I find it to require less effort just to instantiate the SRL16, especially if you are actually using the dynamic capability. Also, a common mistake with inferred fixed length shift registers is the synthesis often does not infer a flip-flop at the SRL16 outputs, which kills clock performance. Synplify will put a flip-flop at the output of a delay, but if you have a register deeper than 17 clocks, it strings together SLR16's with no flip-flops between, which again kills the performance. (This may have been fixed in later versions, I haven't checked). -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759
Reply by ●November 9, 20052005-11-09
its important to note that IF you ever user a reset on a shift register, the a SRL16 CAN'T be inferred as it doesn't have a reset! "Ray Andraka" <ray@andraka.com> wrote in message news:P7Jbf.2$Mi5.0@dukeread07...> Antti Lukats wrote: > > >AGREE 100% > > > >SRL16 is way useful but I do not see it nearly possible that they will be > >used the best > >way with regular synthesis. so the customer should be at least aware ofwhat> >is needed > >to get the SRL16 being used (automatically) or then use them directly. > > > >Antti > > > > > > > Current synthesis pretty much only instantiates the SRL16 as a fixed > length shift register, and then only if the designer didn't put resets > on the registers. There is supposedly a magic incantation in Synplicity > that will infer a dynamic shift, but for th elife of me I have not been > able to get it to infer that consistently, and the words to the > incantation seem to change with each revision of the software. I find > it to require less effort just to instantiate the SRL16, especially if > you are actually using the dynamic capability. Also, a common mistake > with inferred fixed length shift registers is the synthesis often does > not infer a flip-flop at the SRL16 outputs, which kills clock > performance. Synplify will put a flip-flop at the output of a delay, > but if you have a register deeper than 17 clocks, it strings together > SLR16's with no flip-flops between, which again kills the performance. > (This may have been fixed in later versions, I haven't checked). > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >
Reply by ●November 9, 20052005-11-09
Finally got to the heart of the problem. Apparently when porting xco files over to a project for a new device (in this case V4) there is a problem that ISE 7.1 will not upgrade the core to current settings with the new device. This apparently happens even when the logicore is the same version (multiplier in this case). The logicore has to be rebuilt and hence the proper construction for the V4 follows. Thanks for all your help!! -Andrew "Ray Andraka" <ray@andraka.com> wrote in message news:ftybf.3488$IC.1370@dukeread07...> > > Andrew Lohbihler wrote: > >>Thanks John, >> >>The code did work for a Virtex-II and the details of the packing don't >>indicate which column constraint was used. Any idea what constraint should >>be changed to make it work in a Virtex-4? There must be a way to tweak the >>design for the V4 to make it pack similarily as a V2. Any help will do. >> >>Thanks, >>Andrew >> >> > Most of the time, you can re-do the layout so as to not RLOC SRL16s ore > RAM16's into odd columns (this is what you need to do). It is going to > require you to get familiar with the floorplanning that was done for V2 > for this design, and then alter it so that those memory elements only fall > in even columns. > > There is also a bug in the mapper that does not allow RPMs with memory > elements to straddle DSP48 or BRAM columns if there are any memory > elements to the left of the DSP48/BRAM column (in other words, you can't > have any DSP48 or BRAM columns between the RPM's origin and any column > containing either SRL16 or RAM16 elements). That bug was present in 6.x > and 7.1 at least through SP3. I haven't checked to see if it was > corrected in SP4. I don't believe that it was however. In practical > terms, this means any of your macros that use the LUT memory elements must > be less than 4 columns until the bug is fixed, which may require you > breaking them into separately placed pieces (you can do it by just adding > different HU_SET attributes to the elements in each 4 column zone). > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com http://www.andraka.com > "They that give up essential liberty to obtain a little temporary safety > deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >
Reply by ●November 11, 20052005-11-11
This isn't true in Synplify. We can infer resetable static and dynamic read address SRLs and map them into the the primitive SRL16s in a way that we preserve the reset behavior. - Ken McElvain Synplicity, Inc. Simon Peacock wrote:> its important to note that IF you ever user a reset on a shift register, the > a SRL16 CAN'T be inferred as it doesn't have a reset! > > "Ray Andraka" <ray@andraka.com> wrote in message > news:P7Jbf.2$Mi5.0@dukeread07... > >>Antti Lukats wrote: >> >> >>>AGREE 100% >>> >>>SRL16 is way useful but I do not see it nearly possible that they will be >>>used the best >>>way with regular synthesis. so the customer should be at least aware of > > what > >>>is needed >>>to get the SRL16 being used (automatically) or then use them directly. >>> >>>Antti >>> >>> >>> >> >>Current synthesis pretty much only instantiates the SRL16 as a fixed >>length shift register, and then only if the designer didn't put resets >>on the registers. There is supposedly a magic incantation in Synplicity >>that will infer a dynamic shift, but for th elife of me I have not been >>able to get it to infer that consistently, and the words to the >>incantation seem to change with each revision of the software. I find >>it to require less effort just to instantiate the SRL16, especially if >>you are actually using the dynamic capability. Also, a common mistake >>with inferred fixed length shift registers is the synthesis often does >>not infer a flip-flop at the SRL16 outputs, which kills clock >>performance. Synplify will put a flip-flop at the output of a delay, >>but if you have a register deeper than 17 clocks, it strings together >>SLR16's with no flip-flops between, which again kills the performance. >>(This may have been fixed in later versions, I haven't checked). >> >>-- >>--Ray Andraka, P.E. >>President, the Andraka Consulting Group, Inc. >>401/884-7930 Fax 401/884-7950 >>email ray@andraka.com >>http://www.andraka.com >> >> "They that give up essential liberty to obtain a little >> temporary safety deserve neither liberty nor safety." >> -Benjamin Franklin, 1759 >> >> > > >
Reply by ●November 11, 20052005-11-11
I would like to know how.. .. maybe you should check what's generated and the read xapp465 SRL16's have no reset capability. You can however put another ff on the output and reset that instead... but that can't reset the shift register. The only way to do that is to hold the input low (or high) and let it run for 16 clocks. taken from the xapp When a shift register is described in generic HDL code, synthesis tools infer the use of the SRL16 component. Since the SRL16 does not have either synchronous or asynchronous set or reset inputs, and does not have access to all bits at the same time, using such capabilities precludes the use of the SRL16, and the function is implemented in flip-flops. The cascadable shift register (SRLC16) may be inferred if the shift register is larger than 16 bits or if only the Q15 is used. In fact, adding a reset is one way to force a synthesis tool to use flip-flops instead of the SRL16 when flip-flops are preferred for performance or other reasons. If a reset is not needed, simply connect a dummy signal and use an appropriate KEEP attribute to prevent the synthesis tool from optimizing it out of the design. Although the SRL16 shift register does not have a parallel load capability, an equivalent function can be implemented simply by anticipating the load requirement and shifting in the proper data. This requires predictable timing for the load command. since you are inferring hardware that isn't present, it would be rather cool to be able to get it to work as a reset... probably patentable too Simon "Ken McElvain" <ken@synplicity.com> wrote in message news:qzVcf.48310$Tf5.3952@newsread1.mlpsca01.us.to.verio.net...> This isn't true in Synplify. We can infer resetable > static and dynamic read address SRLs and map them into > the the primitive SRL16s in a way that we preserve the > reset behavior. > > - Ken McElvain > Synplicity, Inc. > > Simon Peacock wrote: > > > its important to note that IF you ever user a reset on a shift register,the> > a SRL16 CAN'T be inferred as it doesn't have a reset! > > > > "Ray Andraka" <ray@andraka.com> wrote in message > > news:P7Jbf.2$Mi5.0@dukeread07... > > > >>Antti Lukats wrote: > >> > >> > >>>AGREE 100% > >>> > >>>SRL16 is way useful but I do not see it nearly possible that they willbe> >>>used the best > >>>way with regular synthesis. so the customer should be at least aware of > > > > what > > > >>>is needed > >>>to get the SRL16 being used (automatically) or then use them directly. > >>> > >>>Antti > >>> > >>> > >>> > >> > >>Current synthesis pretty much only instantiates the SRL16 as a fixed > >>length shift register, and then only if the designer didn't put resets > >>on the registers. There is supposedly a magic incantation in Synplicity > >>that will infer a dynamic shift, but for th elife of me I have not been > >>able to get it to infer that consistently, and the words to the > >>incantation seem to change with each revision of the software. I find > >>it to require less effort just to instantiate the SRL16, especially if > >>you are actually using the dynamic capability. Also, a common mistake > >>with inferred fixed length shift registers is the synthesis often does > >>not infer a flip-flop at the SRL16 outputs, which kills clock > >>performance. Synplify will put a flip-flop at the output of a delay, > >>but if you have a register deeper than 17 clocks, it strings together > >>SLR16's with no flip-flops between, which again kills the performance. > >>(This may have been fixed in later versions, I haven't checked). > >> > >>-- > >>--Ray Andraka, P.E. > >>President, the Andraka Consulting Group, Inc. > >>401/884-7930 Fax 401/884-7950 > >>email ray@andraka.com > >>http://www.andraka.com > >> > >> "They that give up essential liberty to obtain a little > >> temporary safety deserve neither liberty nor safety." > >> -Benjamin Franklin, 1759 > >> > >> > > > > > > >
