View Single Post
  #2 (permalink)  
Old 01-04-2006, 02:10 PM
John Adair
Posts: n/a
Default Re: Remapping from Virtex-II to Virtex-4

One problem you have is that in Virtex-4 only half of the slices can support
lut used as memory. In V2 all slices could be used. We have seen similar
things in Spartan-3 particularly if you have used elements such as 32x1 ram.
Alternative you may have tried to use a memory type lut where there isn't
one due to using a RPM or constraint that simply isn't valid.

John Adair
Enterpoint Ltd. - Home of MINI-CAN. The Spartan-3 CAN Bus Development Board.

"Lars" <[email protected]> wrote in message
news:[email protected]
> Anyone done any "what-if" remapping of Virtex-II designs to Virtex-4? I
> wanted to do this to see how the new technology performed, mainly to
> see if it was worth the trouble to upgrade some existing designs. We
> did this quite successfully some years back, stepping from Virtex-E to
> Virtex-II. The main obstacle then was the new size Block RAM going from
> 4kbit to 18 kbit apiece. If we left our Unisim and CoreLib components
> untouched we wasted 3/4 of the RAM, but if the number of Block RAMs in
> the chip was sufficient, all we had to do was to update the
> LOC-constraints for pins and DCM's in the .ucf-file. ISE even managed
> to re-target the Virtex-E DLLs to Virtex-II DCMs. Brilliant!
> So I hoped it would be even better this time, since the Block RAMs are
> the same size, but there seems to be more to this than meets the eye. I
> commented out all the LOC-constraints in the ucf and had a go, after
> resynthesizing to XC4VLX instead of XC2V. But alas, I get a fatal error
> in MAP, complaining about SLICEL and SLICEM types of components. I
> suspect that this has to do with some of our CoreLib components, since
> they are the only place where there might be RLOC constraints in the
> EDIF, but before I go and re-generate all these I am curious to know if
> there is an easier way.
> I am not out to squeeze the full performance out of the XC4VLX right
> now, but would like a "ball-park" figure of what might be expected in
> terms of utilization and speed, before we go ahead and commit to a
> full-scale conversion. That is why I don't want to spend too much time.
> Regards,
> /Lars

Reply With Quote