Anybody understand this ISE 7.1 error, and what to do about it???

"Andrew Lohbihler" <xyz.interactive@rogers.com> schrieb im Newsbeitrag 
news:DLqdnfJwZNJ8wvPenZ2dnUVZ_sOdnZ2d@rogers.com...
> Either way the reason Xilinx did this does not help someone that is 
> porting
> this code to a higher Virtex device. They are stuck with this error with 
> no
> understanding or explanation of how to proceed fixing their code to make 
> it
> work. This is not good support!! Why can't Xilinx make this clear to
> engineers upgrading their devices.
>
> -Andrew
>
>
> "GaLaKtIkUsT" <taileb.mehdi@gmail.com> wrote in message 
> news:1131255526.842676.30480@g44g2000cwa.googlegroups.com...
>> 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?
>>
>

as already said the RPM stuff just is and will be 'family' specific.

and as only half of the slices are SLICEM then the RPM logic
must account for that and fix functions that need SLICEM function
at horisontal offset 2. This is relativly easy todo by calculating
the X values accordingly. The need todo this for existing V2
desing sure is additional PITA thing.

This 'feature' that only 50% of the slice's are now 'good'
old slices (in terms of Virtex slices) is defenetly fully clear
from Xilinx datasheets. Well there are others small things
that are harder do know, like that new devices only support
LVDS output when VCCIO is 2.5 (no 3.3V support)
and that lots of LVDS pins in Virtex4 are 'input' only.
Both the latter 'new fetures' did come as a surprise
to me - while I was testing an already ready made PCB.

--
BTW: Both Actel and Lattice have also a similar
to SLICEM/SLICEL difference between memory
capable and logic only slices - it does reduce
the die size.

Antti

Antti Lukats wrote:

> BTW: Both Actel and Lattice have also a similar
> to SLICEM/SLICEL difference between memory
> capable and logic only slices - it does reduce
> the die size.

Interesting.
The much-hyped SRL16 isn't free after all.
Perhaps Xilinx is discovering that some
designers use a lot of generic rtl code.

        -- Mike Treseler

Mike Treseler wrote:
> Antti Lukats wrote:
> 
>> BTW: Both Actel and Lattice have also a similar
>> to SLICEM/SLICEL difference between memory
>> capable and logic only slices - it does reduce
>> the die size.
> 
> 
> Interesting.
> The much-hyped SRL16 isn't free after all.

Well, half of them being "simple" slice isn't much
of a cost, there is quite always a need for simple
stuff that will fit nicely in a simple LUT4 ...

I wonder, in other brands of FPGA, what if you need
to delay a 16 bits bus by 16 clocks cycles ? You use
simple registers ? That would be 256 registers just
for that ...


> Perhaps Xilinx is discovering that some
> designers use a lot of generic rtl code.

They're inferred quite well for the common cases,
no need to instanciate them explicitly.


	Sylvain

Andrew Lohbihler wrote:
> Either way the reason Xilinx did this does not help someone that is porting
> this code to a higher Virtex device. They are stuck with this error with no
> understanding or explanation of how to proceed fixing their code to make it
> work. This is not good support!! Why can't Xilinx make this clear to
> engineers upgrading their devices.
> 
> -Andrew

The error was EXPLICIT !!  How much MORE do you want?  I've included the 
error below.

The only reason for confusion in this instance is that the person 
receiving the error doesn't know the target silicon well enough to 
understand the issues.  Once explained in plain language, the person 
receiving the error was still unable to interpret the solution.  (I 
answered the question twice in this thread)


The error was:

ERROR:Pack:1142 - A problem was encountered updating the component types 
  within the following shape:
     The RPM "uChip0_Cal1_XA1_TA0/hset"

    A problem was encountered trying to change the type of the component
    containing the following symbols to "SLICEL".

     <LUT, Shift, and FLOP instances showed up here>

    The component is already of type "SLICEM".  The setting of the 
component type is necessary since it is an odd number of columns away 
from a component which already has a type of "SLICEM".  This second 
component contains the following symbols:

     <Two shift and 2 Flop instances showed up here>

This architecture has two types of components, SLICELs and SLICEMs, in 
  alternating columns.  Only SLICEMs can contain RAM symbols.

________________________

Now, do you still want to gripe about Xilinx leaving the designer 
without any idea why his placement failed ?!

Personally, I appreciate the level of support that *is* in the tools. 
It doesn't take much to be able to figure out what's going on if you 
choose to look past your own keyboard.

Sylvain Munaut wrote:

> I wonder, in other brands of FPGA, what if you need
> to delay a 16 bits bus by 16 clocks cycles ? You use
> simple registers ? That would be 256 registers just
> for that ...

Unless you shifted a clock enable
down to the output registers.

> They're inferred quite well for the common cases,
> no need to instanciate them explicitly.

Yes. However you do have to take a side trip
to describe these odd bricks before you describe the wall.

Having no reset is also slightly annoying.

      -- Mike Treseler

"John_H" <johnhandwork@mail.com> wrote in message 
news:8gvbf.8850$dU6.4850@trnddc03...
> Andrew Lohbihler wrote:
>> Either way the reason Xilinx did this does not help someone that is 
>> porting
>> this code to a higher Virtex device. They are stuck with this error with 
>> no
>> understanding or explanation of how to proceed fixing their code to make 
>> it
>> work. This is not good support!! Why can't Xilinx make this clear to
>> engineers upgrading their devices.
>>
>> -Andrew
>
> The error was EXPLICIT !!  How much MORE do you want?  I've included the 
> error below.
>
> The only reason for confusion in this instance is that the person 
> receiving the error doesn't know the target silicon well enough to 
> understand the issues.  Once explained in plain language, the person 
> receiving the error was still unable to interpret the solution.  (I 
> answered the question twice in this thread)
>
>
> The error was:
>
> ERROR:Pack:1142 - A problem was encountered updating the component types 
> within the following shape:
>     The RPM "uChip0_Cal1_XA1_TA0/hset"
>
>    A problem was encountered trying to change the type of the component
>    containing the following symbols to "SLICEL".
>
>     <LUT, Shift, and FLOP instances showed up here>
>
>    The component is already of type "SLICEM".  The setting of the 
> component type is necessary since it is an odd number of columns away from 
> a component which already has a type of "SLICEM".  This second component 
> contains the following symbols:
>
>     <Two shift and 2 Flop instances showed up here>
>
> This architecture has two types of components, SLICELs and SLICEMs, in 
> alternating columns.  Only SLICEMs can contain RAM symbols.
>
> ________________________
>
> Now, do you still want to gripe about Xilinx leaving the designer without 
> any idea why his placement failed ?!
>
> Personally, I appreciate the level of support that *is* in the tools. It 
> doesn't take much to be able to figure out what's going on if you choose 
> to look past your own keyboard.


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

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:

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

"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