Guided MAP/PAR in ISE

80% of the times I ran it, it crashed. The other 20% of the time it took longer than running without it. That includes all versions from 6.1.1-8.1.1 with a range of test cases. I personally think the thing is a joke. It's a great idea, nice sales pitch, and terrible implementation. I submitted some bugs that were supposedly to be fixed in 8.2, but I haven't tried it yet. Apparently it doesn't play nice with overly tight constraints or duplicated registers.

Here's a few thoughts on what I would have expected with "exact" mode and never saw:

If the incoming code

1. has less (or equal) logic than that of the previous run
2. and the logic it has matches that of the previous run
3. and the previous run passed timespecs then that compile should take no time at all.

If the incoming code

1. has all the same logic as the previous run
2. in addition to some more logic then the compile time should take the same amount of time as the difference of the logic on a smaller chip representing the amount of available logic.

If the net names don't match exactly but the logic names do, well good freak, make some assumptions about the net names. That issue turns the whole thing into a major headache.

That's exactly what I am experiencing as well!!!

/Mikhail

Guided place & route worked fabulously back in the schematic entry days (pre

1995 for me). Small changes would re-route in seconds on designs that would take hours for a full place & route. The migration to HDL design and synthesis seems to have made guided routes totally ineffective, although I'm not sure why. Or it may have to do with the "new" Xilinx tools (par, map, etc.) that they originally acquired from NeoCAD back in 1995. I only ever used guided routes with the "old" tools (ppr, etc.).

Anyone who still uses schematic entry had any luck using guided routes with the current ISE tools?

Rob

I used guided par a lot around 2001 with Alliance 3.1i around 2001. It saved me a lot of time as you can see in

However it appears that things have changed a bit since then...

Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Hello Rob,

I am very proud to say I still do some FPGA design work with ViewDraw (oops, I meant DxDesigner...) I have had good luck with exact guide mode in PAR using all ISE tool versions since version 2.1 when using netlists from a schematic tool. There is something to be said for the excruciating level of control you have over the netlist instance and net names when you work with a schematic.

When I have needed this level of control, I found the use of guide in MAP unnecessary... If you consider the circuit of interest -- and you know all the instance and net names -- you simply apply LOC and BEL constraints to nail everything down. This not only fully places everything, but dictates the SLICE packing (and as a side effect, the SLICE instance names) for MAP. There's no "wiggle room" and no need to ask MAP to guide anything. Then you can just use exact guide in PAR.

There is a relatively new mechanism to achieve the same end result, called directed routing constraints. I find this very appealing; you can open a placed and routed design in FPGA Editor, select a net, and click an option to get a directed routing constraint in addition to all of the LOC and BEL constraints for the instances attached to it. It works well and my favorite thing about it is that you put the DIRT constraint into the UCF file, it's all text-based.

For HDL designs, I am sure all of this is frustrating. I haven't had to do it, but based on my experience with schematic designs, I would say that if you require exact guide to deliver a specific, repeatable result -- you really have to design for it up front in what will become non-portable HDL. If you leave it up to chance, it often may help timing closure during place and route but that's gambling, a design technique I do not endorse! Sometimes you win, sometimes you lose.

Incidentally -- things like core dumps, hangs, and crashes are NEVER an expected termination for any vendor's tools. If anyone ever experiences this with Xilinx tools, please let us know by opening a webcase. I know it's asking a favor -- seriously, who has time -- but we greatly appreciate this information especially if you can provide your design files so we can reproduce and debug the error.

Thanks, Eric

(pre

would

I'm

with

Eric,

appreciate

I can't believe you need webcases for this. Take any big design, e.g. GSRD and start playing with it. The tools are guaranteed to crash in a matter of hours. We see all kinds of things all the time. If I opened a case for every mystery I have to resolve here it would be a full-time job. One of the recent problems of today was disappearing check marks in EDK memory map view with which we are supposed to be able to lock memory spaces. The problem was tracked down to corrupted xmp file, which I was able to fix by manual editing despite the warning advising against it (#Please do not modify this file by hand).

/Mikhail

Then you would love for that to have been a Binary file !! [ Another argument against binary files.. ]

-jg

Hello Mikhail,

Filing a webcase is one way to make sure the issue is recorded, so that action may be taken on it. There are, of course, other avenues; FAEs, distributors, or direct contact with Xilinx employees. However, in all routes, the end result is the filing of a software change request. These are prioritized and dispatched to developers. I'm sure this is standard practice for people working on large systems with many software developers, such as the ISE tool set.

I'm sorry to hear you have experienced some trouble. Certainly, it is never our intent to frustrate customers -- the intent of my request was to help us keep other customers from experiencing the same trouble by letting us know about it, so that we may have the opportunity to correct it.

Eric

Eric,

I also wait until I've debugged an issue as far as I can before filing a case. More often than not, I'm asked to submit a test case that shows the problem. Most of the time, it means preparing a test case and then convincing the hotline engineer that there is a problem. I've had runs in the past where fully 1/3rd of my time over a month is spent developing and testing a test case for someone on the hotline that is either too lazy or not bright enough to write his own test case once I describe the issue. It is frustrating, and frankly many times it is more effort than it is worth.

Ray -

And then after you submit the problem with the test case, the support person doesn't bother to look at it.

I submitted a web case recently complaining about XST (not) using the output-enable flip flops in the IOB. I created a test case that showed the issue, submitted it, and then had a Xilinx support person tell me she couldn't re-produce the problem.

I don't think she even tried my simple test code.

Web cases are very frustrating and I seldom get any reasonable solution. I now just submit them so they can be in the Xilinx system so that their s/w engineers can at least know about the problems.

John Providenza

Ray Andraka wrote:

True enough. The solution is usually something to the effect of issuing a CR number and a statement that it will be fixed in the next release (and it often is not). I've got floorplanner issues that have been around for several major releases.

dear MM using guide file might not save time but makes placement and routing is replicated for the new design.

1---try to built incrementally and then see the results in terms of synthesis time. 2-- use tool like PlanAhead with hierarchical design. Its menu (FILE-->

UPDATE NETLIST) and then running PAR on the design in ExploreAhead will definitely reduce PAR time exponentially.

regards MH

MM wrote: