From: mrgs1000@yahoo.com (Mark) Newsgroups: comp.arch.fpga Subject: What do you like/dislike about place and route tools? Date: 30 Nov 2001 11:24:36 -0800 Organization: http://groups.google.com/ Lines: 27 Message-ID: NNTP-Posting-Host: 63.88.196.33 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1007148277 25567 127.0.0.1 (30 Nov 2001 19:24:37 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 30 Nov 2001 19:24:37 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!11081!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feeder.qis.net!sn-xit-02!supernews.com!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12027 I am doing some research on place and route tools. I would like to collect as much information as possible about them. My primary focus is on Xilinx, but I would like to know if there are particular features on other vendors tools that you like or dislike. To be more specific, here are some examples of the kind of information I am looking for: What features do you think are lacking? What types of circuits or conditions do you think the tools fail to handle properly? (if you can send me source for the circuit that would be cool, but I will understand if you cant or don’t want to) What features do you think are really nice? What kinds of controls do you like or wish you had over the place and route process? Please try to be specific about circuits, vendors, and parts since many issues may only be relevant to one vendor’s tools, or even one revision of a vendor’s tools. Thanks, Mark Feel free to email me; my email address is valid (for now anyway). Thanks in advance for any info you can give me. ###### From: allan_herriman.hates.spam@agilent.com (Allan Herriman) Newsgroups: comp.arch.fpga Subject: Re: What do you like/dislike about place and route tools? Date: Sat, 01 Dec 2001 09:23:56 GMT Organization: Agilent Technologies Lines: 74 Message-ID: <3c089783.1596034@netnews.agilent.com> References: NNTP-Posting-Host: cswreg.cos.agilent.com X-Trace: cswtrans.cos.agilent.com 1007198609 21552 130.29.154.45 (1 Dec 2001 09:23:30 GMT) X-Complaints-To: usenet@cswtrans.cos.agilent.com NNTP-Posting-Date: Sat, 1 Dec 2001 09:23:29 +0000 (UTC) X-Newsreader: Forte Free Agent 1.21/32.243 Cache-Post-Path: cswreg.cos.agilent.com!unknown@146.223.162.95 X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!news.isc.org!agilent.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12037 On 30 Nov 2001 11:24:36 -0800, mrgs1000@yahoo.com (Mark) wrote: >I am doing some research on place and route tools. I would like to >collect as much information as possible about them. My primary focus >is on Xilinx, but I would like to know if there are particular >features on other vendors tools that you like or dislike. > >To be more specific, here are some examples of the kind of information >I am looking for: >What features do you think are lacking? >What types of circuits or conditions do you think the tools fail to >handle properly? >(if you can send me source for the circuit that would be cool, but I >will understand if you cant or don’t want to) >What features do you think are really nice? >What kinds of controls do you like or wish you had over the place and >route process? > >Please try to be specific about circuits, vendors, and parts since >many issues may only be relevant to one vendor’s tools, or even >one revision of a vendor’s tools. My primary gripe about the Xilinx tools (apart from the bugs and crashes and the way you can route the same design on multiple PCs with the same version of software and they all route to speed but don't produce identical results even though the source was identical and then some of them don't work when downloaded) is that there is no feedback from placement to Map. Mapping occurs before placement, so the mapper has to make some guesses about how to group logic into slices; where to insert buffers, etc. Most of the time it does a good job. But I sometimes find that I have to change my source code to work around the register ordering feature, for example. (This feature can be disabled, but not on a signal by signal basis. If it's disabled for the whole chip the results are usually really bad.) Register ordering causes Map to group logic into slices according to the labels on the logic. E.g. sig_0 and sig_1 will end up in the same slice. This is great for arithmetic (essential, actually, unless you're hand placing everything) but not so good if two flip flops from completely unrelated parts of the design end up in the same slice, which really fouls up your floorplan. Once Map has done the damage, there is nothing PAR can do to fix it. Workarounds (for VHDL) include: - Changing std_logic_vectors to arrays of single element std_logic_vectors. This makes the generated labels all end in "_0" which prevents Register Ordering. (Thanks to Hamish Moffatt for this one.) - Applying placement attributes in the source code. These comments apply to VirtexE parts, 60-80% utilised, 100-170MHz-ish clocks. 3.x & 4.x tools. That said, I think the quality of the back end tools is much better than the quality of the front end tools. I tried my current design (several tens of thousands of lines of VHDL) with some different versions of a leading VHDL synthesiser: version result 6.0.0 Dr. Watson 6.2.0 works when downloaded to fpga 6.2.3 doesn't work when downloaded 6.2.4 doesn't work when downloaded 7.0.1 doesn't compile (parser bug) 7.0.2 doesn't compile (parser bug) 1 out of 6 ain't bad! (Better than 0 out of 6.) Regards, Allan. ###### Message-ID: <3c0a0812$0$19497$afc38c87@news.optusnet.com.au> From: hamish@cloud.net.au Subject: Re: What do you like/dislike about place and route tools? Newsgroups: comp.arch.fpga References: User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (Linux/2.2.18 (i586)) Date: 02 Dec 2001 10:53:06 GMT Lines: 56 NNTP-Posting-Host: 203.164.66.244 X-Trace: 1007290386 19497 203.164.66.244 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!53539!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!logbridge.uoregon.edu!newsfeed.dacom.co.kr!intgwlon.nntp.telstra.net!news1.optus.net.au!optus!spool01.syd.optusnet.com.au!spool.optusnet.com.au!210.49.20.119.MISMATCH!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12059 Mark wrote: > To be more specific, here are some examples of the kind of information > I am looking for: > What features do you think are lacking? I agree with everything Allan said. To add to that, I think the place and the route stages are too separate (or at least they appear to be). Last week I was helping someone route an update to an existing design. For some reason, PAR (3.3i SP8 or 4.1i SP2, tried both) was placing one large block of logic a long way from its source signals. There was no area constraint, RLOCs, LOCs etc which would cause it do that; the placer just decided. Then the router spent 11-15 hours trying to route it unsuccessfully. We got net delays of 8 ns, on flip-flop to flip-flop paths with a 5.5ns constraint. In this case, the placer picked a completely stupid placement for this block and the router spent the next half day trying to fix it. It never realised that no amount of rerouting was going to halve the net delay. A simple area_group constraint for this block fixed the problem and got the PAR time down to the usual 2-3 hours for this design. Some other things I would like: multipass PAR should learn from previous iterations. Right now, multipass just varies the cost table (random number seeds) and there is nothing learnt from previous iterations. Also, the place and route tool should be multi-threaded to make use of multiple CPU systems. Surely some part of the process can be done in parallel? We have dual CPU systems everywhere now. Maybe if it helped the runtime enough we could justify a 4 CPU system. Repeatability is essential, as Allan said. Unfortunately, current Xilinx PAR seems to have some issues in this area. Here's another design flow wishlist. MAP has a feature called register ordering, which tries to group my_vector[0] and my_vector[1] etc into the same slice. There urgently needs to be a constraint which can be put in to disable this behaviour for individual signals. If you expand a signal into a vector manually to lower the fan out, you can end up with your signals grouped into pairs, which is often completely useless. I have started using arrays of std_logic_vector(0 to 0) (VHDL) to get around this problem! Finally, the tools should never crash :-) 4.1i (any service pack) leaks memory in a multipass run, and after a few iterations will eventually chew up all the memory on your PC and crash. This has been confirmed by Xilinx. Just a few thoughts. I must say that in my experience, 4.1i is a dramatic improvement on 3.3i. I'm very happy with the 4.1i results in a nice fast Virtex-II part. regards, Hamish -- Hamish Moffatt VK3SB ###### Message-ID: <3C0A7C62.78B07A46@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: What do you like/dislike about place and route tools? References: <3c0a0812$0$19497$afc38c87@news.optusnet.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 88 Date: Sun, 02 Dec 2001 19:08:37 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 1007320117 24.13.238.93 (Sun, 02 Dec 2001 11:08:37 PST) NNTP-Posting-Date: Sun, 02 Dec 2001 11:08:37 PST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!44541!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!hub1.nntpserver.com!news-out.spamkiller.net!propagator-la!news-in-la.newsfeeds.com!newshub2.rdc1.sfba.home.com!news.home.com!news1.wwck1.ri.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12068 My biggest beef with the Xilinx placer is when there is more than one level of logic, the placer puts the second level a long distance away regardless of timing constraints. The first level gets placed with the associated flip-flop (I'm numbering in reverse order so that the output of the first outputs to the flipflop) as it should. If you place the flip-=flops, then as long as the combinatorial logic is only one level you wind up with a good placement. Go to a second level, and you'll have to place the LUTs too (which is a pain compared with using a regular expression). I think that is the most greivous of the placer sins, but there are others. hamish@cloud.net.au wrote: > Mark wrote: > > To be more specific, here are some examples of the kind of information > > I am looking for: > > What features do you think are lacking? > > I agree with everything Allan said. To add to that, I think the place > and the route stages are too separate (or at least they appear to be). > > Last week I was helping someone route an update to an existing design. > For some reason, PAR (3.3i SP8 or 4.1i SP2, tried both) was placing one > large block of logic a long way from its source signals. There was no > area constraint, RLOCs, LOCs etc which would cause it do that; the > placer just decided. Then the router spent 11-15 hours trying to route > it unsuccessfully. We got net delays of 8 ns, on flip-flop to flip-flop > paths with a 5.5ns constraint. > > In this case, the placer picked a completely stupid placement for this > block and the router spent the next half day trying to fix it. It never > realised that no amount of rerouting was going to halve the net delay. > A simple area_group constraint for this block fixed the problem and > got the PAR time down to the usual 2-3 hours for this design. > > Some other things I would like: multipass PAR should learn from previous > iterations. Right now, multipass just varies the cost table (random > number seeds) and there is nothing learnt from previous iterations. Yes that would be really good. Even if it could infer the next cost table instead of just walking through (I know that is probably harder than iterating on the placement). > > > Also, the place and route tool should be multi-threaded to make use > of multiple CPU systems. Surely some part of the process can be > done in parallel? We have dual CPU systems everywhere now. Maybe > if it helped the runtime enough we could justify a 4 CPU system. > > Repeatability is essential, as Allan said. Unfortunately, current > Xilinx PAR seems to have some issues in this area. > > Here's another design flow wishlist. MAP has a feature called > register ordering, which tries to group my_vector[0] and my_vector[1] > etc into the same slice. There urgently needs to be a constraint which > can be put in to disable this behaviour for individual signals. If > you expand a signal into a vector manually to lower the fan out, > you can end up with your signals grouped into pairs, which is > often completely useless. I have started using arrays of > std_logic_vector(0 to 0) (VHDL) to get around this problem! > > Finally, the tools should never crash :-) 4.1i (any service pack) > leaks memory in a multipass run, and after a few iterations will > eventually chew up all the memory on your PC and crash. This > has been confirmed by Xilinx. > > Just a few thoughts. I must say that in my experience, 4.1i > is a dramatic improvement on 3.3i. I'm very happy with the > 4.1i results in a nice fast Virtex-II part. > > regards, > Hamish > -- > Hamish Moffatt VK3SB -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 ###### Message-ID: <3C0BBEEF.A576434A@mail.com> From: John_H X-Mailer: Mozilla 4.75 [en]C-CCK-MCD (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: What do you like/dislike about place and route tools? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 37 Date: Mon, 03 Dec 2001 18:05:36 GMT NNTP-Posting-Host: 192.65.17.17 X-Complaints-To: postmaster@tek.com X-Trace: news-west.eli.net 1007402736 192.65.17.17 (Mon, 03 Dec 2001 11:05:36 MST) NNTP-Posting-Date: Mon, 03 Dec 2001 11:05:36 MST Organization: Tektronix NewsReader Service Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!logbridge.uoregon.edu!news-west.eli.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12096 I love seeing comments form others that reinforce the gripes I've had over time. My experience with the Altera MaxPlus-II tools is dated with no Quartus to back mu up but what I saw then is consistent with what I continue to see in Xilinx: Nobody is doing "critical route" placement. In my opinion, the best way to place and route a design is to figure out what paths will be the most difficult to route. When the delay paths with two carry chains and four levels of logic are routed first, the paths with two levels of logic should be cake to P&R with fewer resources available. I don't care if my logic goes from one corner to another if it doesn't impact the timing for that path and the critical routing resources have already been used. What does irk me is finding part of my few tight paths getting placed inefficiently. To have these critical paths in different rows in my Altera design or in different, non-adjacent CLBs in my Xilinx designs is irresponsible. The Xilinx mapper in particular works against the concept of a critical route based place and route. The idea that the design should 1) be placed then 2) be routed doesn't work (to any level of efficiency). The P&R tool should be 1) place, 2) route, 3) place, 4) route, 5) place, etc.... At least in (an upcoming servicepack of) the version 4.1i tools there's some attention given to critical routes, though more of a ripup and retry approach. Strike that, I think they refer to it as a retry: no ripup of any paths that meet timing. This is a big step in the right direction but still may be too little, too late in the P&R process to give the leaps in performance. With the proper P&R strategies, the silicon that's been designed to kick some serious butt will finally be able to do just that. Having the P&R kick the engineer in the butt really needs to stop. I hope the research you're doing is toward a very good end! ###### Message-ID: <3C0BCD7B.11B1AB7E@exponentmedia.deletethis.com> From: Andy Peters X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: What do you like/dislike about place and route tools? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 28 Date: Mon, 03 Dec 2001 19:07:46 GMT NNTP-Posting-Host: 24.221.131.16 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 1007406466 24.221.131.16 (Mon, 03 Dec 2001 11:07:46 PST) NNTP-Posting-Date: Mon, 03 Dec 2001 11:07:46 PST Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Mon, 03 Dec 2001 11:07:48 PST (newsmaster1.prod.itd.earthlink.net) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.direct.ca!look.ca!newsfeed1.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12098 Well, here's a complaint about Lattice's tools. For some reason, Lattice thinks that designers care about how many logic levels it takes to implement a function. See, I don't care. All I care is that the finished design meets my timing constraints (and fits). Problem is, Lattice's tools don't know a timing constraint from a hole in the wall. What their tools expect you to do is to pick a combination of fitter options, press "go" and after the place and route completes (if, in fact, it does), you have to manually go through the timing reports to see if you win or lose. And when you lose, you have to go back in and pick a different bunch of options. The fitter "effort" switch doesn't do what you think it does, it just picks a different algorithm. The "Explore" feature is broken. If you want to take advantage of the fast I/O output enables, you have to set a constraint in a constraint file that's call "end critical path." And the fitter will then warn you that there's "no combinational logic..." to minimize if you drive your output enable from a flop. (It still "does the right thing," but the warning is stupid.) I've told the Lattice rep more than once: I want to be able to set a period constraint and I/O timing constraints, push the "start" button, and go get a cup of coffee or get some lunch, and come back and find my chip either routed or failed to meet timing (or it wouldn't fit). I haven't even mentioned how unroutable their chips are. ---a ###### From: Petter Gustad Newsgroups: comp.arch.fpga Subject: Re: What do you like/dislike about place and route tools? Organization: 502 You are not allowed to talk Lines: 23 Sender: petter@filestore.home.gustad.com Message-ID: <87elmcgckd.fsf@filestore.home.gustad.com> References: X-Home-Page: http://gustad.com X-Newsreader: Gnus v5.7/Emacs 20.7 NNTP-Posting-Host: 146.172.32.190 X-Complaints-To: news-abuse@nextra.no NNTP-Posting-Date: Tue, 04 Dec 2001 00:02:06 MET X-Trace: readme.online.no 1007420526 146.172.32.190 Date: 03 Dec 2001 23:32:02 +0100 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!skynet.be!skynet.be!news.tele.dk!small.news.tele.dk!213.131.157.171!newsfeed1.wineasy.se!newsfeed1.ulv.nextra.no!nextra.com!news1.oke.nextra.no.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12135 mrgs1000@yahoo.com (Mark) writes: > I am doing some research on place and route tools. I would like to > collect as much information as possible about them. My primary focus > is on Xilinx, but I would like to know if there are particular > features on other vendors tools that you like or dislike. I like performance. Most place and route algorithms are building some kind of search tree with an estimate of timing, congestion, etc. I think these applications would run quite effectively on clusters of workstations (or PC's). I would like to see place and route tools implementing distributed algorithms so I could increase the throughput (not necessarily linearly) by throwing cheap $2000 PC's at the problem... Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.com ###### Message-ID: <3C0C28AD.D2B96044@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: What do you like/dislike about place and route tools? References: <3C0BCD7B.11B1AB7E@exponentmedia.deletethis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 46 Date: Tue, 04 Dec 2001 01:35:57 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 1007429757 24.13.238.93 (Mon, 03 Dec 2001 17:35:57 PST) NNTP-Posting-Date: Mon, 03 Dec 2001 17:35:57 PST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!out.nntp.be!propagator-SanJose!in.nntp.be!news-in-sanjose!newshub2.rdc1.sfba.home.com!news.home.com!news1.wwck1.ri.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12110 Wow, This sounds exactly like my complaints about Lattice 5 years ago (I haven't used Lattice in a while). So sad to hear that nothing has changed. Andy Peters wrote: > Well, here's a complaint about Lattice's tools. > > For some reason, Lattice thinks that designers care about how many logic > levels it takes to implement a function. See, I don't care. All I care > is that the finished design meets my timing constraints (and fits). > Problem is, Lattice's tools don't know a timing constraint from a hole > in the wall. What their tools expect you to do is to pick a combination > of fitter options, press "go" and after the place and route completes > (if, in fact, it does), you have to manually go through the timing > reports to see if you win or lose. And when you lose, you have to go > back in and pick a different bunch of options. The fitter "effort" > switch doesn't do what you think it does, it just picks a different > algorithm. The "Explore" feature is broken. > > If you want to take advantage of the fast I/O output enables, you have > to set a constraint in a constraint file that's call "end critical > path." And the fitter will then warn you that there's "no combinational > logic..." to minimize if you drive your output enable from a flop. (It > still "does the right thing," but the warning is stupid.) > > I've told the Lattice rep more than once: I want to be able to set a > period constraint and I/O timing constraints, push the "start" button, > and go get a cup of coffee or get some lunch, and come back and find my > chip either routed or failed to meet timing (or it wouldn't fit). > > I haven't even mentioned how unroutable their chips are. > > ---a -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 ###### From: Ken McElvain Newsgroups: comp.arch.fpga Subject: Re: What do you like/dislike about place and route tools? Date: Mon, 03 Dec 2001 17:47:49 -0800 Organization: The ISP formerly known as Best Lines: 53 Message-ID: <3C0C2B45.8040508@synplicity.com> References: <3C0BBEEF.A576434A@mail.com> NNTP-Posting-Host: synvpn.synplicity.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: nntp1.ba.best.com 1007430468 56927 209.157.48.1 (4 Dec 2001 01:47:48 GMT) X-Complaints-To: abuse@best.com NNTP-Posting-Date: Tue, 4 Dec 2001 01:47:48 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.gtei.net!news.voicenet.com!news2.best.com!nntp1.ba.best.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12115 John_H wrote: > I love seeing comments form others that reinforce the gripes I've had over > time. > > My experience with the Altera MaxPlus-II tools is dated with no Quartus to > back mu up but what I saw then is consistent with what I continue to see > in Xilinx: > > Nobody is doing "critical route" placement. Take a look at the TOPS technology in Amplify. It does it's own complete placement of a region while doing timing optimization on the logic. It doesn't do the whole chip but regions can be pretty large. Virtex and Virtex-E only. http://www.synplicity.com/about/pressreleases/SYB-101final.html > > In my opinion, the best way to place and route a design is to figure out > what paths will be the most difficult to route. When the delay paths with > two carry chains and four levels of logic are routed first, the paths with > two levels of logic should be cake to P&R with fewer resources available. > I don't care if my logic goes from one corner to another if it doesn't > impact the timing for that path and the critical routing resources have > already been used. What does irk me is finding part of my few tight paths > getting placed inefficiently. To have these critical paths in different > rows in my Altera design or in different, non-adjacent CLBs in my Xilinx > designs is irresponsible. > > The Xilinx mapper in particular works against the concept of a critical > route based place and route. The idea that the design should 1) be placed > then 2) be routed doesn't work (to any level of efficiency). The P&R tool > should be 1) place, 2) route, 3) place, 4) route, 5) place, etc.... At > least in (an upcoming servicepack of) the version 4.1i tools there's some > attention given to critical routes, though more of a ripup and retry > approach. Strike that, I think they refer to it as a retry: no ripup of > any paths that meet timing. This is a big step in the right direction but > still may be too little, too late in the P&R process to give the leaps in > performance. > > With the proper P&R strategies, the silicon that's been designed to kick > some serious butt will finally be able to do just that. Having the P&R > kick the engineer in the butt really needs to stop. > > I hope the research you're doing is toward a very good end! > > ###### Message-ID: <3c0cb7c9$0$21612$afc38c87@news.optusnet.com.au> From: hamish@cloud.net.au Subject: Re: What do you like/dislike about place and route tools? Newsgroups: comp.arch.fpga References: <3C0BBEEF.A576434A@mail.com> User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (Linux/2.2.18 (i586)) Date: 04 Dec 2001 11:47:21 GMT Lines: 17 NNTP-Posting-Host: 203.164.66.244 X-Trace: 1007466441 21612 203.164.66.244 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news1.optus.net.au!optus!spool01.syd.optusnet.com.au!spool.optusnet.com.au!210.49.20.119.MISMATCH!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12130 John_H wrote: > Nobody is doing "critical route" placement. Good point. I had to do something like this by hand using guide files etc earlier in the year. Really ugly, but the end result worked out OK. Unfortunately, the guide files aren't compatible between 3.x and 4.x! > With the proper P&R strategies, the silicon that's been designed to kick > some serious butt will finally be able to do just that. Having the P&R > kick the engineer in the butt really needs to stop. Well put. cheers Hamish -- Hamish Moffatt VK3SB ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: What do you like/dislike about place and route tools? Date: Tue, 04 Dec 2001 11:37:01 -0500 Lines: 37 Message-ID: <3C0CFBAD.FA7A6417@yahoo.com> References: <3C0BBEEF.A576434A@mail.com> <3C0C2B45.8040508@synplicity.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVZfZX6SNVpAwVAvh1zxOkVYKx9oQElO4rEs/t4PGcRIShyjE5IqFn/4 X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 4 Dec 2001 16:36:02 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12107 Ken McElvain wrote: > > John_H wrote: > > > I love seeing comments form others that reinforce the gripes I've had over > > time. > > > > My experience with the Altera MaxPlus-II tools is dated with no Quartus to > > back mu up but what I saw then is consistent with what I continue to see > > in Xilinx: > > > > Nobody is doing "critical route" placement. > > Take a look at the TOPS technology in Amplify. It does it's own > complete placement of a region while doing timing optimization on > the logic. It doesn't do the whole chip but regions can be pretty > large. Virtex and Virtex-E only. > > http://www.synplicity.com/about/pressreleases/SYB-101final.html Does this take timing constraints into account? If the front end tools are considering timing, then it needs to work with the same timing constraint database that the backend tool does. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: What do you like/dislike about place and route tools? Date: Tue, 04 Dec 2001 11:44:33 -0500 Lines: 42 Message-ID: <3C0CFD71.F7838A3D@yahoo.com> References: <87elmcgckd.fsf@filestore.home.gustad.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVaGD2LhEUyNeuK1WxpYuInc4eCZ4W70YlR1DbPalChEmuX+nm4Gvoy6 X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 4 Dec 2001 16:43:40 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12106 Petter Gustad wrote: > > mrgs1000@yahoo.com (Mark) writes: > > > I am doing some research on place and route tools. I would like to > > collect as much information as possible about them. My primary focus > > is on Xilinx, but I would like to know if there are particular > > features on other vendors tools that you like or dislike. > > I like performance. > > Most place and route algorithms are building some kind of search tree > with an estimate of timing, congestion, etc. I think these > applications would run quite effectively on clusters of workstations > (or PC's). > > I would like to see place and route tools implementing distributed > algorithms so I could increase the throughput (not necessarily > linearly) by throwing cheap $2000 PC's at the problem... > > Petter Back when Neocad was a third party P&R tool vendor, they supported this on Sun workstations. I assume that it was a useful feature since it was taking hours to P&R a 4000 gate FPGA on a PC. But then they sold out to Xilinx and we have a "merged" tool compatible with the Xilinx marketing goals. Does anyone know if they still support distributed processing on workstations? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### Message-ID: <3C0D10E7.18E64594@mail.com> From: John_H X-Mailer: Mozilla 4.75 [en]C-CCK-MCD (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: What do you like/dislike about place and route tools? References: <3C0BBEEF.A576434A@mail.com> <3C0C2B45.8040508@synplicity.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 25 Date: Tue, 04 Dec 2001 18:07:36 GMT NNTP-Posting-Host: 192.65.17.17 X-Complaints-To: postmaster@tek.com X-Trace: news-west.eli.net 1007489256 192.65.17.17 (Tue, 04 Dec 2001 11:07:36 MST) NNTP-Posting-Date: Tue, 04 Dec 2001 11:07:36 MST Organization: Tektronix NewsReader Service Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!logbridge.uoregon.edu!news-west.eli.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12157 Ken McElvain wrote: > John_H wrote: > > > Nobody is doing "critical route" placement. > > Take a look at the TOPS technology in Amplify. The improvements gained by Automated TOPS are touted as minor improvements in timing (5%-15% on your posters?), but granted - improvements. The Interactive TOPS is what was touted by Synplify and Xilinx both at the recent EDA Front to Back conference. The manual intervention to say that "duh, these circuit elements need to be close to each other" is, in my heavily biased opinion, a stopgap that should never need to be done. I suggested that I could hire my 8 year old nephew to run the Interactive TOPS and get much better results than the tools will provide. No extensive special knowledge needed. My arguement was simply that the place and route process should be - hands off - doing the critical routes first, backfilling from there. I thank you folks at Synpicity for trying to make up for other vendors' shortcomings. I'm just sad that the tool pricing for this stop-gap for inadequate tools has kept me in the business of editing my .ucf files rather than spinning the TOPS. ###### Message-ID: <3C0D1271.27F2DAD8@mail.com> From: John_H X-Mailer: Mozilla 4.75 [en]C-CCK-MCD (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: What do you like/dislike about place and route tools? References: <87elmcgckd.fsf@filestore.home.gustad.com> <3C0CFD71.F7838A3D@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 16 Date: Tue, 04 Dec 2001 18:14:10 GMT NNTP-Posting-Host: 192.65.17.17 X-Complaints-To: postmaster@tek.com X-Trace: news-west.eli.net 1007489650 192.65.17.17 (Tue, 04 Dec 2001 11:14:10 MST) NNTP-Posting-Date: Tue, 04 Dec 2001 11:14:10 MST Organization: Tektronix NewsReader Service Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!logbridge.uoregon.edu!news-west.eli.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12158 rickman wrote: > Back when Neocad was a third party P&R tool vendor, they supported this > on Sun workstations. I assume that it was a useful feature since it was > taking hours to P&R a 4000 gate FPGA on a PC. > > But then they sold out to Xilinx and we have a "merged" tool compatible > with the Xilinx marketing goals. Does anyone know if they still support > distributed processing on workstations? The only thing I know is available is distributed Multipass Place & Route. You can set up multiple workstation "nodes" but each node gets a complete pass of the P&R. If you're to the point you need to eek out that last half nanosecond and have a small number of fast machines this method of distributed P&R can be very helpful. For one design, though, nada. ###### Message-ID: <3C0D167D.CB0DD112@exponentmedia.deletethis.com> From: Andy Peters X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: What do you like/dislike about place and route tools? References: <3C0BCD7B.11B1AB7E@exponentmedia.deletethis.com> <3C0C28AD.D2B96044@andraka.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 60 Date: Tue, 04 Dec 2001 18:31:33 GMT NNTP-Posting-Host: 24.221.131.16 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 1007490693 24.221.131.16 (Tue, 04 Dec 2001 10:31:33 PST) NNTP-Posting-Date: Tue, 04 Dec 2001 10:31:33 PST Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Tue, 04 Dec 2001 10:31:28 PST (newsmaster1.prod.itd.earthlink.net) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!out.nntp.be!propagator-SanJose!in.nntp.be!news-in-sanjose!cyclone.bc.net!newsfeed.direct.ca!look.ca!newsfeed1.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread2.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12160 Ray, Get this: I installed the 9.0 version of the tools on the machine, and tried to "import" a design from the previous generation. Nope, can't do that. OK, so I created a new "project." Maybe it'll let me import my pin-constraint file, so I don't have to retype (or worse, use a point-and-click GUI) to re-enter the 192 pins I've constrained? Nope, can't do that, either. This Sucks Eggs. -a Ray Andraka wrote: > > Wow, This sounds exactly like my complaints about Lattice 5 years ago (I > haven't used Lattice in a while). So sad to hear that nothing has changed. > > Andy Peters wrote: > > > Well, here's a complaint about Lattice's tools. > > > > For some reason, Lattice thinks that designers care about how many logic > > levels it takes to implement a function. See, I don't care. All I care > > is that the finished design meets my timing constraints (and fits). > > Problem is, Lattice's tools don't know a timing constraint from a hole > > in the wall. What their tools expect you to do is to pick a combination > > of fitter options, press "go" and after the place and route completes > > (if, in fact, it does), you have to manually go through the timing > > reports to see if you win or lose. And when you lose, you have to go > > back in and pick a different bunch of options. The fitter "effort" > > switch doesn't do what you think it does, it just picks a different > > algorithm. The "Explore" feature is broken. > > > > If you want to take advantage of the fast I/O output enables, you have > > to set a constraint in a constraint file that's call "end critical > > path." And the fitter will then warn you that there's "no combinational > > logic..." to minimize if you drive your output enable from a flop. (It > > still "does the right thing," but the warning is stupid.) > > > > I've told the Lattice rep more than once: I want to be able to set a > > period constraint and I/O timing constraints, push the "start" button, > > and go get a cup of coffee or get some lunch, and come back and find my > > chip either routed or failed to meet timing (or it wouldn't fit). > > > > I haven't even mentioned how unroutable their chips are. > > > > ---a > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: What do you like/dislike about place and route tools? Date: Tue, 04 Dec 2001 14:04:34 -0500 Lines: 49 Message-ID: <3C0D1E42.C629D585@yahoo.com> References: <87elmcgckd.fsf@filestore.home.gustad.com> <3C0CFD71.F7838A3D@yahoo.com> <3C0D1271.27F2DAD8@mail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVb1wqVA2KwWPJ4DkI5XmMzPzALOeepDdyg3ZbICYxIMbV53G3TBnLC8 X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 4 Dec 2001 19:03:56 GMT X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12136 John_H wrote: > > rickman wrote: > > > Back when Neocad was a third party P&R tool vendor, they supported this > > on Sun workstations. I assume that it was a useful feature since it was > > taking hours to P&R a 4000 gate FPGA on a PC. > > > > But then they sold out to Xilinx and we have a "merged" tool compatible > > with the Xilinx marketing goals. Does anyone know if they still support > > distributed processing on workstations? > > The only thing I know is available is distributed Multipass Place & Route. > You can set up multiple workstation "nodes" but each node gets a complete > pass of the P&R. If you're to the point you need to eek out that last half > nanosecond and have a small number of fast machines this method of > distributed P&R can be very helpful. For one design, though, nada. To be honest, I don't think the Neocad tool was anything different. Their sales point was that you could run "many" passes of P&R over a weekend by tasking up all of your machines. Keep in mind that this was at a time when it took hours to P&R a simple chip because PCs were so slow by comparison (~66 MHz IIRC) and Windows was just being supported so that made the tools run even slower (although this was likely only the GUI as the P&R was most likely still a DOS app). Today you only need hours on a machine to P&R if you are doing >1000 Kgate designs. But certainly anything you can do to get the cycle time down would be useful. I wonder if anyone has done a calculation of the wasted CPU cycles on all the machines sitting on desks in the world. I know that some efforts have been made to utilize these CPU cycles such as SETI and encryption cracking. Anyone know of any compute intensive EDA applications that can be distributed over PCs? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: "Pallek, Andrew [CAR:CN34:EXCH]" Newsgroups: comp.arch.fpga Subject: Re: What do you like/dislike about place and route tools? Date: Fri, 07 Dec 2001 09:17:29 -0500 Organization: Nortel Networks Lines: 10 Message-ID: <3C10CF78.65CE998@americasm01.nt.com> References: <3C0BCD7B.11B1AB7E@exponentmedia.deletethis.com> NNTP-Posting-Host: wcars19u.ca.nortel.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.cwix.com!torn!qcarhaaa.nortelnetworks.com!bcarh189.ca.nortel.com!zcarh46f.ca.nortel.com!bcarh8ac.ca.nortel.com!bcarh8ab.ca.nortel.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12219 Another Beef about Lattice tools is that sometimes they output truncated .jed files when fitting on UNIX platforms. You think everything fit fine, but your programming file is only about 1/8 of the size it needs to be to be valid, and downloadable. Spitting out useless junk is not a desireable feature unless you need a quasi-random number generator, which was not what I was hoping for. I haven't seen this problem on the PC platform. And you think that the place and route would be doing the same thing on both platforms. Apparently not. ###### Message-ID: <3C167A64.4CD84F61@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: What do you like/dislike about place and route tools? References: <3c0a0812$0$19497$afc38c87@news.optusnet.com.au> <3C0A7C62.78B07A46@andraka.com> <3C165D02.2A4F126D@Boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 48 Date: Tue, 11 Dec 2001 21:27:01 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 1008106021 24.13.238.93 (Tue, 11 Dec 2001 13:27:01 PST) NNTP-Posting-Date: Tue, 11 Dec 2001 13:27:01 PST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!news1.wwck1.ri.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12304 The additional timing through the latch is substantial. It is better to floorplan it. The problem with usign the grpahical floorplanner for combinatorial luts is that synthesis often changes the names. In critical stuff, we just instantiate a lut or an fmapped version of the logic, which seems to be about the same amount of work and no less confusing later when the design is revisited. It is the not so critical stuff where I don't want to be mucking about with the code (to instantiate luts or insert other implants) that would do fine as long as the second layer of logic was at least somewhere reasonably close. As it is, the automatic placement seems to put second layers of logic halfway across the chip, even if there is a ton of open space and all the gozintas and gozoutas are all locked down close to where it should go. "Jason T. Wright" wrote: > I've dealt with the LUT placement issue at times by inserting a > [logically] superfluous transparent latch (always enabled, such as with > RESET--correct polarity selected) that I can easily control the > placement of. In the architectures that support it, of course (such as > 4000XL); there is usually only a small timing penalty going through the > latch, which is more than made up for by the better routing. > > Jason T. Wright > > Ray Andraka wrote: > > > > My biggest beef with the Xilinx placer is when there is more than one level > > of logic, the placer puts the second level a long distance away regardless > > of timing constraints. The first level gets placed with the associated > > flip-flop (I'm numbering in reverse order so that the output of the first > > outputs to the flipflop) as it should. If you place the flip-=flops, then > > as long as the combinatorial logic is only one level you wind up with a good > > placement. Go to a second level, and you'll have to place the LUTs too > > (which is a pain compared with using a regular expression). I think that is > > the most greivous of the placer sins, but there are others. > > -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 ###### Message-ID: <3C16DBF1.7B7D71BB@home.com> From: Phil Hays Organization: "Real email is phil-hays aATt homeDOTcom" X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: What do you like/dislike about place and route tools? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 22 Date: Wed, 12 Dec 2001 04:20:40 GMT NNTP-Posting-Host: 204.127.202.216 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc52 1008130840 204.127.202.216 (Wed, 12 Dec 2001 04:20:40 GMT) NNTP-Posting-Date: Wed, 12 Dec 2001 04:20:40 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn4feed!wn1feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc52.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12359 Mark wrote: > I am doing some research on place and route tools. I would like to > collect as much information as possible about them. My primary focus > is on Xilinx, but I would like to know if there are particular > features on other vendors tools that you like or dislike. Tilde (~) in front of timing values in the timing report (.twr). For Xilinx tools, this means that the path's delay could not be exactly calculated by the normal method. To quote the documentation: "In a timing report, a tilde (~) preceding a delay value indicates that the delay value is approximate. Values with the tilde cannot be calculated exactly because of excessive delays, resistance, or capacitance on the net, that is, the path is too complex to calculate accurately. The tilde (~) also means that the path may exceed the numerical value listed next to the tilde by as much as 20%" -- Phil Hays ###### Message-ID: <3C16DCA4.36196BEF@home.com> From: Phil Hays Organization: "Real email is phil-hays aATt homeDOTcom" X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: What do you like/dislike about place and route tools? References: <3C16DBF1.7B7D71BB@home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 39 Date: Wed, 12 Dec 2001 04:23:39 GMT NNTP-Posting-Host: 204.127.202.216 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc51 1008131019 204.127.202.216 (Wed, 12 Dec 2001 04:23:39 GMT) NNTP-Posting-Date: Wed, 12 Dec 2001 04:23:39 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!87951!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn4feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc51.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:12358 Replying to my own note. > Tilde (~) in front of timing values in the timing report (.twr). > > For Xilinx tools, this means that the path's delay could not be exactly > calculated by the normal method. To quote the documentation: > > "In a timing report, a tilde (~) preceding a delay value indicates that the > delay value is approximate. Values with the tilde cannot be calculated exactly > because of excessive delays, resistance, or capacitance on the net, that is, the > path is too complex to calculate accurately. > The tilde (~) also means that the path may exceed the numerical value listed > next to the tilde by as much as 20%" The best solution I know of is to add the "PENALIZE TILDE=##" command to the (.pcf) file. This command defaults to zero, and a value of 20 (twenty percent) should be the minimum. As the pcf file is both written by map and is a source to building the design correctly, this can cause problems with source control, so I have in my command file: # # Copy blank pcf file to design name before starting design # copy ..\blank.pcf design_name.pcf # blank.pcf is in the source directory, on level up, and is source controlled. Example blank.pcf SCHEMATIC START ; SCHEMATIC END ; PENALIZE TILDE=20; -- Phil Hays