From: "Erik Wahlstrom" Newsgroups: comp.arch.fpga Subject: Vertex Place & Route Time Lines: 25 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Fri, 16 Feb 2001 19:42:31 GMT NNTP-Posting-Host: 63.204.7.2 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 982352551 63.204.7.2 (Fri, 16 Feb 2001 11:42:31 PST) NNTP-Posting-Date: Fri, 16 Feb 2001 11:42:31 PST Organization: EarthLink Inc. -- http://www.EarthLink.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.dplanet.ch!news-ge.switch.ch!newsfeeds.belnet.be!news.belnet.be!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:4674 We are looking for ways to decrease the place, route and synthesis time required for the Vertex II 1000 and above. Does anyone have any experience comparing, Pentium II vs. Pentium III at the same frequency? I remember reading something about a "shift by N number of bits" instruction which was removed in P3. What about Cache size. Is there a signifigent speedup going to the 2MB cache. What about interleaving main memory. What about RAMBUS main memory? I know RAMBUS get it's speed up from pipelining. What about striped filesystems across 2 to 4 UltraSCSI disks? No doubt all of the above will help but has anybody actually done the comparative cost analysis? Cheers Erik ###### From: "Simon Bacon" Newsgroups: comp.arch.fpga Subject: Re: Vertex Place & Route Time Date: Fri, 16 Feb 2001 20:23:11 -0000 Message-ID: <982357938.17395.0.nnrp-13.9e9832fa@news.demon.co.uk> References: NNTP-Posting-Host: tile.demon.co.uk X-NNTP-Posting-Host: tile.demon.co.uk:158.152.50.250 X-Trace: news.demon.co.uk 982357938 nnrp-13:17395 NO-IDENT tile.demon.co.uk:158.152.50.250 X-Complaints-To: abuse@demon.net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Lines: 33 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!fr.clara.net!heighliner.fr.clara.net!grolier!dispose.news.demon.net!news.demon.co.uk!demon!tile.demon.co.uk!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:4701 Of course, nothing approaches the gain from floorplanning... "Erik Wahlstrom" wrote in message news:Hofj6.1623$JS2.206543@newsread2.prod.itd.earthlink.net... > We are looking for ways to decrease the place, route and synthesis time > required for the Vertex II 1000 and above. > > Does anyone have any experience comparing, > > Pentium II vs. Pentium III at the same frequency? > I remember reading something about a "shift by N number of bits" instruction > which was removed in P3. > > What about Cache size. Is there a signifigent speedup going to the 2MB > cache. > > What about interleaving main memory. > > What about RAMBUS main memory? I know RAMBUS get it's speed up from > pipelining. > > What about striped filesystems across 2 to 4 UltraSCSI disks? > > No doubt all of the above will help but has anybody actually done the > comparative cost analysis? > > Cheers Erik > > ###### Message-ID: <3A8DB618.26E03212@algor.co.uk> From: Rick Filipkiewicz X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Vertex Place & Route Time References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Algorithmics Ltd. Cache-Post-Path: mudchute.algor.co.uk!root@oval.algor.co.uk X-Cache: nntpcache 2.4.0b2 (see http://www.nntpcache.org/) Lines: 41 Date: Fri, 16 Feb 2001 23:22:00 +0000 NNTP-Posting-Host: 62.254.210.251 X-Complaints-To: abuse@ntlworld.com X-Trace: news2-win.server.ntlworld.com 982365725 62.254.210.251 (Fri, 16 Feb 2001 23:22:05 GMT) NNTP-Posting-Date: Fri, 16 Feb 2001 23:22:05 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!uni-erlangen.de!news-nue1.dfn.de!news-lei1.dfn.de!news-fra1.dfn.de!news0.de.colt.net!colt.net!newspeer.clara.net!news.clara.net!news5-gui.server.ntli.net!ntli.net!news2-win.server.ntlworld.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:4661 Erik Wahlstrom wrote: > We are looking for ways to decrease the place, route and synthesis time > required for the Vertex II 1000 and above. > > Does anyone have any experience comparing, > > Pentium II vs. Pentium III at the same frequency? I just went from a PII-450 to a PIII-600 in what was otherwise the same box & saw very little improvement in P&R time. Down from 58 min for a 75% used XCV400 to 51-52. > What about Cache size. Is there a signifigent speedup going to the 2MB > cache. > When we first built our NT systems we hadn't heard about the bug where, by default, the L2 cache size is set to 0. I thought ``oh goody'' & turned it on - only 512K. Found ~squat improvement. > What about interleaving main memory. > > What about RAMBUS main memory? I know RAMBUS get it's speed up from > pipelining. Basically this is the right area to look at since PAR is fundamentally memory access bounded. I'd forget RAMBUS & go for the AMD system with the fastest DDR you can afford. This applies to the synth & simulation tools as well. ** An important note ** If you are running Win-NT you must have enough memory that it never starts to page. Once it does its performance drops like a brick through a greenhouse roof - for any reasonable size design NT paging => you might as well take that week off you've been planning. I would suggest an absolute min of 384M and preferrably 512. For the big devices then make sure your motherboard supports 1GB. ###### From: "Simon Bacon" Newsgroups: comp.arch.fpga Subject: Re: Vertex Place & Route Time Date: Sat, 17 Feb 2001 10:38:21 -0000 Message-ID: <982410691.1645.0.nnrp-02.9e9832fa@news.demon.co.uk> References: <3A8DB618.26E03212@algor.co.uk> NNTP-Posting-Host: tile.demon.co.uk X-NNTP-Posting-Host: tile.demon.co.uk:158.152.50.250 X-Trace: news.demon.co.uk 982410691 nnrp-02:1645 NO-IDENT tile.demon.co.uk:158.152.50.250 X-Complaints-To: abuse@demon.net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6600 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Lines: 28 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!psinet-eu-nl!newsfeeds.belnet.be!news.belnet.be!skynet.be!newshub1.nl.home.com!news.nl.home.com!bullseye.news.demon.net!news.demon.co.uk!demon!tile.demon.co.uk!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:4716 "Rick Filipkiewicz" wrote in message news:3A8DB618.26E03212@algor.co.uk... > ** An important note ** If you are running Win-NT you must have enough > memory that it never starts to page. Once it does its performance > drops like a brick through a greenhouse roof - for any reasonable > size design NT paging you might as well take that week off you've > been planning. I would suggest an absolute min of 384M and > preferrably 512. For the big devices then make sure your motherboard > supports 1GB. Is this also true for a reasonably floor-planned design? In other words, if the P&R tools have a simpler problem to solve, do they need less memory? Or is the memory requirement largely determined by the size of the target device? And does anyone know the memory footprint of P&R for the largest Virtex and Virtex-II devices? Another data point: a very full XCV300, approx 50% floorplanned, routed just fine in 256MB with no visible paging. ###### Message-ID: <3A8ECB7F.94F96DC5@algor.co.uk> From: Rick Filipkiewicz X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Vertex Place & Route Time References: <3A8DB618.26E03212@algor.co.uk> <982410691.1645.0.nnrp-02.9e9832fa@news.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Algorithmics Ltd. Cache-Post-Path: mudchute.algor.co.uk!root@oval.algor.co.uk X-Cache: nntpcache 2.4.0b2 (see http://www.nntpcache.org/) Lines: 41 Date: Sat, 17 Feb 2001 19:05:35 +0000 NNTP-Posting-Host: 62.254.210.251 X-Complaints-To: abuse@ntlworld.com X-Trace: news2-win.server.ntlworld.com 982436737 62.254.210.251 (Sat, 17 Feb 2001 19:05:37 GMT) NNTP-Posting-Date: Sat, 17 Feb 2001 19:05:37 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!fr.clara.net!heighliner.fr.clara.net!grolier!btnet-peer0!btnet!news5-gui.server.ntli.net!ntli.net!news2-win.server.ntlworld.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:4712 Simon Bacon wrote: > "Rick Filipkiewicz" wrote in message > news:3A8DB618.26E03212@algor.co.uk... > > > ** An important note ** If you are running Win-NT you must have enough > > memory that it never starts to page. Once it does its performance > > drops like a brick through a greenhouse roof - for any reasonable > > size design NT paging you might as well take that week off you've > > been planning. I would suggest an absolute min of 384M and > > preferrably 512. For the big devices then make sure your motherboard > > supports 1GB. > > Is this also true for a reasonably floor-planned design? In other > words, if the P&R tools have a simpler problem to solve, do they > need less memory? Or is the memory requirement largely determined > by the size of the target device? > Interesting question. > > And does anyone know the memory footprint of P&R for the largest Virtex > and Virtex-II devices? > > Another data point: a very full XCV300, approx 50% floorplanned, routed > just fine in 256MB with no visible paging. BTW I wasn't saying I need all the 384M. The current design uses ~150M. Its just that I like to get on with other things while PAR is grinding along in the background. For example I'll typically start the post-synth simulation & PAR at the same time and ModelSim is burning another 80-100M. If you add in the 60-70M allocated to NT + its buffers I can get over 300M useage in a couple of mouse clicks. I then start playing around with NGDBUILD to check out some new constraints for the next iteration & NT goes into free-fall.