View Single Post
  #9 (permalink)  
Old 02-22-2005, 01:07 PM
Brian Drummond
Guest
 
Posts: n/a
Default Re: Issues with a batch of Virtex-II chips

On Mon, 21 Feb 2005 17:30:42 +0100, "IgI" <[email protected]> wrote:

>> Have you re-run timing analysis on the 5.3 design, but using the latest
>> timing analyser and latest speed files?

>
>No, because I don't think there's any timing issue here. The logic is
>trivial and runs at low speed.


Maybe not, unless there are hold time or skew issues, not properly
covered by older speed files. I would try the newer speed files on the
"suspect" design just to check.

>> With 6.1, have you tried MPPR (multi-pass pacement and routing)?
>> Sometimes modifying the placement (in FPGA editor) of failing paths and
>> re-running "re-entrant routing" can fix problems, if there are only a
>> small number of failing paths.

>
>Yes, I have. I tried 6.1, 6.2 and 6.3. It's always the same story.
>Placer/Router does a lousy job. Either the constraints can't be met or the
>router can't connect all the nets. ISE 5.2 SP3 completes without any errors
>and reports 7 logic levels for the constraint. On the other hand ISE 6.x
>reports 16 logic levels for the same constraint.


That can be illusory, if 9+ of those 16 levels are carry logic. It may
reflect relatively small differences in placement or routing getting
on/off the carry chain.

But I have found (a) a LUT connected to a long carry chain but placed on
the other side of the chip ... and (with a heavily floorplanned design,
where the placer can't do that) (b) a signal taking 3ns to get from one
CLB to its immediate neighbour.

The former (if an isolated incident) can be fixed in FPGA editor,
the latter either reflects severe congestion (whatever happened to
"view/congestion map" in the floorplanner?) or a very lazy router.

>In my experience (for the Virtex-II family) if the design takes less than
>~90% of chip resources then the results of ISE 6.x are similar to the ISE
>5.2 SP3, sometimes even better, but as soon as design takes more than 95% of
>all chip resources then ISE 6.x gives up. Similarly I still use ISE 3.3 for
>SpartanXL and Spartan2 designs, because ISE 4.2 or newer don't produce the
>desired results. I know a lot depends on the synthesis tool (I'm using
>synplicity)...


Interesting. I didn't know that about the 5.x-6.x problems, but Ray
Andraka has commented on the relative performance of 3.3 vs later in the
past. (Google may help a little) I'm still using 3.3 in "production"!

My experience so far with 6.x (Webpack) is that it will never meet
reasonable constraints, but radically overconstraining it will improve
results.

For example, if I want 10 ns, and ask for it, I get 10.5 ns. But if I
ask for 9 ns I get 9.8, (or 10.1) and if I ask for 8 ns I get 9.5 ns...
I just made up those numbers but they represent the trend I've seen.
If the resulting design passes timing analysis at 10.0 ns, I can't see
any reason not to use it...

>Thanks for you suggestions,
>Igor Bizjak


Thanks. I've not pushed such high resource usages, so it's interesting
to hear tales from people pushing the chips hard in other respects.

- Brian


Reply With Quote