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 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
> >>
> >>
> >
> >
> >
>

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
>>
>>
> 
> 
> 

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
>
> 

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
>
>

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

"Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag 
news:2zybf.3489$IC.2133@dukeread07...
> GaLaKtIkUs&#4294967295; 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.com

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

"Ray Andraka" <ray@andraka.com> wrote in message 
news:EEybf.3490$IC.959@dukeread07...
> Andrew Lohbihler wrote:
>
>>
>>John, I understand what you are saying and appreciate the follow through 
>>of my error message. but given your solution as;
>>
>>So 1) find all your memory elements, and 2) move them around so they're
>>either all in even RLOC columns or they're all in odd RLOC columns.
>>
>>I don't understand how to implement this in ISE. How do you set the 
>>constraint in ISE to ensure that the components end up in SLICEMs. Or 
>>possibly how do you do that manually, or at the silicon level using ISE 
>>tools?
>>
>>-Andrew
>>
> Andrew,
>
> You are going to have to find out where the placement is specified.  It 
> may be in the source, in a UCF file or in the floorplanner.  If you are 
> using RPM macros from a 3rd party, you may have to either recompile those 
> macros with fixes or contact the 3rd party for a modified macro suitable 
> for V4.  Basically, you have to modify the placement where ever it was 
> specified.
>
> -- 
> --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
>
>

I use Xilinx cores here, specifically the Logicore multiplier (Multiplier 
7.0) in the Xilinx Core Generator. This is the code near where the mapping 
failed. The "multiplier construction" parameter field apparently has no 
selector for "ExtremeDSP" slices but does have a "Luts" selector. Perhaps I 
have an old Logicore that was not updated for the V4. The documentation 
recommends using either field to construct for a V4, and clearly shows that 
the ExtremeDSP selector should be there. Anyone have experience with thes 
cores to know this??

-Andrew 

Andrew Lohbihler wrote:

>
>John, I understand what you are saying and appreciate the follow through of 
>my error message. but given your solution as;
>
>So 1) find all your memory elements, and 2) move them around so they're
>either all in even RLOC columns or they're all in odd RLOC columns.
>
>I don't understand how to implement this in ISE. How do you set the 
>constraint in ISE to ensure that the components end up in SLICEMs. Or 
>possibly how do you do that manually, or at the silicon level using ISE 
>tools?
>
>-Andrew 
>
>  
>
Andrew,

You are going to have to find out where the placement is specified.  It 
may be in the source, in a UCF file or in the floorplanner.  If you are 
using RPM macros from a 3rd party, you may have to either recompile 
those macros with fixes or contact the 3rd party for a modified macro 
suitable for V4.  Basically, you have to modify the placement where ever 
it was specified.

-- 
--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

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.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

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