Guided MAP/PAR in ISE

Hi all,

I was wondering if anyone had succeded in saving time by using guided
MAP/PAR. I personally find that every time I want to use it, even in the
most obvious cases when 99.9% of design hasn't changed,  I then have to
re-run everything from scratch anyway...


Thanks,
/Mikhail

> I was wondering if anyone had succeded in saving time by using guided
> MAP/PAR. I personally find that every time I want to use it, even in the
> most obvious cases when 99.9% of design hasn't changed,  I then have to
> re-run everything from scratch anyway...

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.

"Brannon" <brannonking@yahoo.com> wrote in message
news:1154014545.550301.275490@m73g2000cwd.googlegroups.com...
>
> 80% of the times I ran it, it crashed. The other 20% of the time it
> took longer than running without it.

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

/Mikhail

"Petter Gustad" <newsmailcomp6@gustad.com> wrote in message 
news:87d5bqopve.fsf@gustad.com...
>
> 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
>
> http://tinyurl.com/kv3al
>
> However it appears that things have changed a bit since then...
>
> Petter

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 

"Brannon" <brannonking@yahoo.com> writes:

> > I was wondering if anyone had succeded in saving time by using guided
> > MAP/PAR. I personally find that every time I want to use it, even in the
> > most obvious cases when 99.9% of design hasn't changed,  I then have to
> > re-run everything from scratch anyway...
> 
> 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

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 

http://tinyurl.com/kv3al

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

"RobJ" <rob@abc.net> wrote in message
news:_c7yg.25554$Z67.20356@tornado.socal.rr.com...

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

Eric,

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

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

MM wrote:
> Eric,
> 
> 
>>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.
> 
> 
> 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).

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

Hello Mikhail,

> I can't believe you need webcases for this.

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 Crabill wrote:

> Hello Mikhail,
> 
> 
>>I can't believe you need webcases for this.
> 
> 
> 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.