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

"Andrew Lohbihler" schrieb im Newsbeitrag news:TfCdndMvzOo2TPbenZ2dnUVZ snipped-for-privacy@rogers.com...

your desing requires for some reason SLICEMs to be placed at invalid relative positions. This is the error saying. Why it happens I can not tell, some problem with placement constraints.

Antti

Unlike earlier Virtex family devices, the Virtex-4 has half the slices allowed as memory-capable. The RPM cannot have shift registers or distributed CLB SelectRAM (single port or dual port) in both odd AND even RLOC columns. The SLICEL has a lookup table that's logic only while the SLICEM has LUTs that can be loaded and read as a single port memory, a dual-port memory, or a shift register.

If the RPM was done for a project in a Virtex-IIPro or older device, you'll need to tweak it for the "odd or even column only" constraint of the Virtex-4. If your RPM is fresh for this design, simply reconfigure it for the constraint you now know is getting in your way.

- John_H

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

"The RPM cannot have shift registers or distributed CLB SelectRAM (single port or dual port) in both odd AND even RLOC columns. The SLICEL has a lookup table that's logic only while the SLICEM has LUTs that can be loaded and read as a single port memory, a dual-port memory, or a shift register."

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.

This will allow all you memory elements to be RLOCed into SLICEM slices.

- John_H

Andrew Lohbihler 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?

I'd say it's more because even if you do use the slice as memory & shift egister, it's unlikely that you need ALL of them to be capable of that ...

So by only making half of them with this capability, you don't loose much but I'd guess you win quite some space & complexity.

Sylvain

I believe it been said before by Xilinx.. that it was done to reduce the silicon size. Most designers don't use them so its no great loss. And you shouldn't be using RLOCs from an older version silicon with a new version anyway... the mapping is usually done for optimum timings and/or placement... it doesn't automatically follow that what was best for a Vertex

2 is best for a vertex 3 or 4.

Simon

:-O Vitex 3 ?? never heard about it !!

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

"Andrew Lohbihler" schrieb im Newsbeitrag news:DLqdnfJwZNJ8wvPenZ2dnUVZ snipped-for-privacy@rogers.com...

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

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

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

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

Sylvain

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

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:

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.

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

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

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

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