Place and Route Algorithms

Ray,

I'm not the best person to talk further on this topic, so I'll direct you to:

formatting link

and read Steve Lass' article, specifically thru page 8.

For those who don't want to download the whole issue of Xcell:

formatting link

and not have to deal with pdf, either.

You will miss the lovely artwork, but the content is the same.

He details the new Xplorer tool which (I think) finds the optimal we used to find, and then creates the proper constraints and command file so that subsequent compiles do not have to start from scratch.

formatting link

for the details, courtesy of Hitesh Patel.

He also mentions PlanAhead, as well.

Thanks to Steve & Hitesh for the timely appearance of this!

And thanks to you Ray for the opportunity to post these useful links ...

Austin

Reply to
Austin Lesea
Loading thread data ...

Is the direct connection lost, because something else uses that path, or could something as trivial as a 'length optimise' pass fix this ?

It does not sound like floor-planned nets, are being given first-bite at the resource, either....

This does not sound like rocket science to fix, and if I were SW quality manager, I would place this issue at the top of "very rigorous quality of results metrics" Xilinx supposedly use.... Seems the Xilinx mindset thinks if things 'on average' are better, those cases where it goes backwards, don't really matter...

Once the tools have met timing, wouldn't a simple length reduction (which the place tools DO know) be a fast and efficent way to clean up the lazy nets ? length should correlate pretty well with delay and capacitance... Users would tolerate if this power task took longer, even a weekend run 'shaker algorithm' - when the code is only nearly working, power is less of a concern :)

-jg

Reply to
Jim Granville

Maybe they could ask Ray for some examples, so they can _find_ the cases where the tools go backwards - instead of burying that in the nonsense of statistical averages ? Heck, they might even find that ALL designs benefit from the code cleanup ?!

-jg

Reply to
Jim Granville

C'mon, they don't understand why a hardware engineer would want to use revision control or automated building (Makefiles) for designs. If they did, the tools wouldn't spit files all over the place, and there wouldn't be lossage like one tool requiring the part type given as xc2s100e-ft256-6 and another needing the same info as xc2s100e-6-ft256.

Arrrrrgh ...

-a

Reply to
Andy Peters

I've seen -timing break a design's timing badly. (This was a design that for some reason P&R'd a lot better at an effort level of 'medium' rather than 'high');

Jeremy

Reply to
Jeremy Stringer

Agreed completely.

Agreed completely (including Ray's points about newer versions not being necessarily better than older ones).

To add a few datapoints behind John's comment about losing 1.5 nanoseconds after changing non-critical logic, we have been fighting this type of thing at least every month (often more frequently), for three years now. Always using the latest software version available at the time, in all of our larger and/or higher speed designs (2V3000,

2VP7, 2VP40, and now LX25 designs), we have come to expect that it will take many runs to stumble upon one that meets timing when we make truely trivial changes (I'm talking about things that would make the term "non-critical changes" look like massive changes... stuff like changing a version ID or fixing an inversion problem going to a LUT). I am not kidding or exaggerating in any way when I say that it's an event worthy of commenting on to coworkers and minor celebration when a change is made to one of the above designs and it meets timing the first or second try. That just should not be the case.

BTW, the designs were done by different people with different styles. The only thing in common is that they are all hierarchical, and they all tend to use up a fair amount of the device (LUT utilization between

75 and 91%).

Marc

Reply to
Marc Randolph

Globally optimal placement and routing is an NP-hard problem even for multilayer PCBs, so all you can expect is only a set of approximations, if you want to receive that placement in a reasonable time.

Best regards Piotr Wyderski

--
"If you were plowing a field, which would you rather use?
Two strong oxen or 1024 chickens?" -- Seymour Cray
Reply to
Piotr Wyderski

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.