From: "Francisco Rodriguez" Newsgroups: comp.arch.fpga Subject: Floorplanner RPM. How to use it? Date: Fri, 18 Oct 2002 21:42:07 +0200 Organization: U.P.V. Lines: 23 Message-ID: NNTP-Posting-Host: prodrig.disca.upv.es X-Trace: polaris.cc.upv.es 1034969056 32212 158.42.53.4 (18 Oct 2002 19:24:16 GMT) X-Complaints-To: newsmaster@upv.es NNTP-Posting-Date: 18 Oct 2002 19:24:16 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.rediris.es!news.uv.es!news.upv.es!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22200 Hello all I'm working with Xilinx ISE 4.1 tools. I have a small design manually floorplanned and have created an RPM with all the logic, but without IOBs or BUFGs. Now I want to use this RPM as a design black block in a larger design. How do I instantiate it into my VHDL model? Or am I completely wrong on the use of RPMs? Regards Francisco ==================================================== Francisco Rodriguez Ballester (prodrig@disca.upv.es) Dept. DISCA, EUI - Univ. Politecnica de Valencia c/Camino de Vera s/n, E-46022, VALENCIA (SPAIN) tlf: +(34) 96 387 75 77 - fax: +(34) 96 387 75 79 ==================================================== ###### Message-ID: <3DB0679F.79D00326@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: Floorplanner RPM. How to use it? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 55 Date: Fri, 18 Oct 2002 19:57:54 GMT NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: news1.east.cox.net 1034971074 68.15.41.165 (Fri, 18 Oct 2002 15:57:54 EDT) NNTP-Posting-Date: Fri, 18 Oct 2002 15:57:54 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!newsfeed.stueberl.de!cox.net!p01!news1.east.cox.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22189 If it was created in the floorplanner, you are restricted to using it in that design, at least as of v4.2i. You can export it as a UCF file, which essentially puts LOCs on all the pieces, so you could bring it into another design only if the device is the same size and the hierarchical names are unchanged. Not all that useful, I know. The problem with the floorplanner (well, one of many problems actually) is that it is not hierarchical: it works on a flat representation of your design, so you wind up having to floorplan each copy of multiple identical instances instead of doing it once unless you do the floorplanning in your source. You can also create hard macros using the FPGA editor and bring them in as black boxes into your source. I don't like doing that because it makes simulation and timing analysis difficult. We put RLOCs directly into our VHDL so that we end up with placed RPMs that can be used in any design without having to go through floorplanning every time. In that case, you just instantiate the RPM as a component in the HDL code (and stick an RLOC on that component if it is forming a larger RPM). Of course, Xilinx says they've never heard of people making big RPMs out of smaller ones like this, and the 5.1 tools barf on big RPMs...but that is beside the point. Francisco Rodriguez wrote: > Hello all > > I'm working with Xilinx ISE 4.1 tools. I have a small design manually > floorplanned and have created an RPM with all the logic, but > without IOBs or BUFGs. > > Now I want to use this RPM as a design black block in a larger design. > How do I instantiate it into my VHDL model? > > Or am I completely wrong on the use of RPMs? > > Regards > Francisco > ==================================================== > Francisco Rodriguez Ballester (prodrig@disca.upv.es) > Dept. DISCA, EUI - Univ. Politecnica de Valencia > c/Camino de Vera s/n, E-46022, VALENCIA (SPAIN) > tlf: +(34) 96 387 75 77 - fax: +(34) 96 387 75 79 > ==================================================== -- --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: "Jan Gray" Newsgroups: comp.arch.fpga Subject: Re: Floorplanner RPM. How to use it? Date: Fri, 18 Oct 2002 13:42:31 -0700 Organization: Gray Research LLC Lines: 45 Message-ID: References: <3DB0679F.79D00326@andraka.com> NNTP-Posting-Host: 04.2e.94.06 X-Server-Date: 18 Oct 2002 20:42:35 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!newsfeed.stueberl.de!cox.net!newsfeed1.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22213 "Ray Andraka" wrote > ... Of course, Xilinx says they've never heard of people making > big RPMs out of smaller ones like this ... I can only presume that you spoke to someone who didn't know what they were talking about. Hierarchical composition is specifically supported by RPMs, has been since day one, and is an essential facility. For example, in March '01, I PAR'd a design that filled a V600E with 60 processors. That was 60 instances of a processor RPM (actually 30 and 30 mirror-image processor RPMs), each processor RPM a composition of some bus interface RPMs and a datapath RPM, each datapath RPM a composition of some register RPMs, LUT RAM RPMs, ALU RPMs, addmux RPMs, etc. That design would have taken ages to process through your favorite synthesis tool in one lump. So you synthesize *one* 8x6x4 LUT processor RPM and instantiate it as a black box 60 times, RLOC'ing or RLOC_ORIGIN'ing each one (instead of making a single, monolithic, monstrous 48x72x4 LUT RPM). I asked Synplicity to provide a convenient one-step process to synthesize my design of 60 copies of an RPM by something like a black-box primitive that only expands (and then reuses) one identical submodule of a design (instead of wastefully expanding 60 topologically-identical-copies-but-with-renamed-synthesized-netnames-submodu les-and-their-sub-submodules-etc.) No interest -- so I continued to run Synplicity twice, once to synthesize one instance of the processing-element submodule (disabling I/O insertion) and once to synthesize the 60 instantiations (with the submodule converted to a black box instantiation). To put it another way, if I mark a module as syn_hier="hard", e.g. "hands off, don't optimize into or out of my module, please!", why would two instantiations of the module generate two quasi-identical-copies of the expanded module in the EDIF, when one shared copy would suffice? This is also the project where I complained to Synplicity that Synplify generates EDIF with unused VCC and GND nets for each of the many, many thousands of explicitly technology mapped 1-LUT ALU and addmux RPMs modules in my design, causing several minutes of unused-net warnings from MAP (IIRC) for each build cycle. See also http://www.fpgacpu.org/log/mar02.html#020302. Jan Gray, Gray Research LLC ###### Message-ID: <3DB07978.CFF2C4E4@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: Floorplanner RPM. How to use it? References: <3DB0679F.79D00326@andraka.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 94 Date: Fri, 18 Oct 2002 21:14:03 GMT NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: news1.east.cox.net 1034975643 68.15.41.165 (Fri, 18 Oct 2002 17:14:03 EDT) NNTP-Posting-Date: Fri, 18 Oct 2002 17:14:03 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!newsfeed.stueberl.de!cox.net!p01!news1.east.cox.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22191 I wish that were the case. This is something that broke in 5.1 that causes map to take 25+ hours to complete where it completed in less than 2 hours on a machine with half the speed and memory (and paging like crazy on that machine) using 4.2. It isn't hierarchical composition that is broken, it is RPMs with a large number of slices (the open case has about 17,000 slices and consists of 50 identical tiles). In this case, I also ran the tile separately through synplify for exactly the same reasons you did, and then algorithmically placed the tiles in the next level up. I've also had the same beef about synplify, but haven't bothered to complain there. At least Xilinx pretends to listen. Do me a favor, run some of your big RPMs through 5.1sp1 and see what it does to the map time. In my case, it expanded it more than 10x. Then if/when you see the problem, complain to xilinx loudly about it. You can reference case 444377. Xilinx appears to be sweeping this one under the rug with a 'no one else has this problem so perhaps your methodology is flawed' type of response. The exact quote was: "The developers have identified the bottlenecks in map 5.1i sp1. It seems are sensetive to the 17,000 slice RPM in your design. This was an unforseen use case which the new map architecture neglects. This is the only design anyone at Xilinx has seen that uses an RPM this large. Therefore, the developers are wondering what problem this RPM solves. Either you are trying to solve a problem no other designer is trying to solve, or this is just a different approach to it. Would you mind explaining what problem you are solving with this giant RPM and why you have chosen this method as opposed to some other method. " Likewise, anyone else who uses a similar methodology, please try it out under 5.1sp1, and if it slows down map, complain to Xilinx about it. Any additional input to Xilinx to convince them that it isn't an off-the-wall approach would be welcome (and I would like to be copied on any case, if you care to). Jan Gray wrote: > "Ray Andraka" wrote > > ... Of course, Xilinx says they've never heard of people making > > big RPMs out of smaller ones like this ... > > I can only presume that you spoke to someone who didn't know what they were > talking about. Hierarchical composition is specifically supported by RPMs, > has been since day one, and is an essential facility. > > For example, in March '01, I PAR'd a design that filled a V600E with 60 > processors. That was 60 instances of a processor RPM (actually 30 and 30 > mirror-image processor RPMs), each processor RPM a composition of some bus > interface RPMs and a datapath RPM, each datapath RPM a composition of some > register RPMs, LUT RAM RPMs, ALU RPMs, addmux RPMs, etc. > > That design would have taken ages to process through your favorite synthesis > tool in one lump. So you synthesize *one* 8x6x4 LUT processor RPM and > instantiate it as a black box 60 times, RLOC'ing or RLOC_ORIGIN'ing each one > (instead of making a single, monolithic, monstrous 48x72x4 LUT RPM). > > I asked Synplicity to provide a convenient one-step process to synthesize my > design of 60 copies of an RPM by something like a black-box primitive that > only expands (and then reuses) one identical submodule of a design (instead > of wastefully expanding 60 > topologically-identical-copies-but-with-renamed-synthesized-netnames-submodu > les-and-their-sub-submodules-etc.) No interest -- so I continued to run > Synplicity twice, once to synthesize one instance of the processing-element > submodule (disabling I/O insertion) and once to synthesize the 60 > instantiations (with the submodule converted to a black box instantiation). > > To put it another way, if I mark a module as syn_hier="hard", e.g. "hands > off, don't optimize into or out of my module, please!", why would two > instantiations of the module generate two quasi-identical-copies of the > expanded module in the EDIF, when one shared copy would suffice? > > This is also the project where I complained to Synplicity that Synplify > generates EDIF with unused VCC and GND nets for each of the many, many > thousands of explicitly technology mapped 1-LUT ALU and addmux RPMs modules > in my design, causing several minutes of unused-net warnings from MAP (IIRC) > for each build cycle. > > See also http://www.fpgacpu.org/log/mar02.html#020302. > > Jan Gray, Gray Research LLC -- --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: <3DB08AE3.5050909@synplicity.com> From: Ken McElvain User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Floorplanner RPM. How to use it? References: <3DB0679F.79D00326@andraka.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 63 Date: Fri, 18 Oct 2002 22:29:04 GMT NNTP-Posting-Host: 209.157.48.1 X-Complaints-To: abuse@verio.net X-Trace: sea-read.news.verio.net 1034980144 209.157.48.1 (Fri, 18 Oct 2002 22:29:04 GMT) NNTP-Posting-Date: Fri, 18 Oct 2002 22:29:04 GMT Organization: Verio Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news.stealth.net!news.stealth.net!logbridge.uoregon.edu!HSNX.atgi.net!sjc-peer.news.verio.net!news.verio.net!sea-read.news.verio.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22194 Jan Gray wrote: > "Ray Andraka" wrote > >>... Of course, Xilinx says they've never heard of people making >>big RPMs out of smaller ones like this ... >> > ... > > I asked Synplicity to provide a convenient one-step process to synthesize my > design of 60 copies of an RPM by something like a black-box primitive that > only expands (and then reuses) one identical submodule of a design (instead > of wastefully expanding 60 > topologically-identical-copies-but-with-renamed-synthesized-netnames-submodu > les-and-their-sub-submodules-etc.) No interest -- so I continued to run > Synplicity twice, once to synthesize one instance of the processing-element > submodule (disabling I/O insertion) and once to synthesize the 60 > instantiations (with the submodule converted to a black box instantiation). I belive that the feature you want has just gone out in the 7.2 Beta. Why don't you download it and look up what we call a "locked" compile point. This is part of the MultiPoint technology, another part is an automatic (other than selecting compile points) incremental flow that extends through synthesis into both Altera and Xilinx P&R tools. The results are better than a black box based bottom up flow because the timing of the subdesign is taken into account when optimizing other parts of the design. It uses LogicLock for Altera and the new incremental P&R flow based on area groups in Xilinx. I think you will also find the excess VCC/GND net problem you mention below about below fixed in 7.2 as well. > > To put it another way, if I mark a module as syn_hier="hard", e.g. "hands syn_hier="hard" means that we won't change the port list of the module - no boundary optimization, but differences in timing flow through and can cause different instances to produce different structures. > off, don't optimize into or out of my module, please!", why would two > instantiations of the module generate two quasi-identical-copies of the > expanded module in the EDIF, when one shared copy would suffice? > > This is also the project where I complained to Synplicity that Synplify > generates EDIF with unused VCC and GND nets for each of the many, many > thousands of explicitly technology mapped 1-LUT ALU and addmux RPMs modules > in my design, causing several minutes of unused-net warnings from MAP (IIRC) > for each build cycle. > > See also http://www.fpgacpu.org/log/mar02.html#020302. > > Jan Gray, Gray Research LLC > > > ###### From: "Jan Gray" Newsgroups: comp.arch.fpga Subject: Re: Floorplanner RPM. How to use it? Date: Fri, 18 Oct 2002 16:37:04 -0700 Organization: Gray Research LLC Lines: 47 Message-ID: References: <3DB0679F.79D00326@andraka.com> <3DB08AE3.5050909@synplicity.com> NNTP-Posting-Host: 04.2e.94.06 X-Server-Date: 18 Oct 2002 23:37:08 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!newsfeed.stueberl.de!cox.net!newsfeed1.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22212 "Ken McElvain" wrote > I belive that the feature you want has just gone out in the 7.2 Beta. > Why don't you download it and look up what we call a "locked" > compile point. Thank you, I will, as time permits. And thanks for addressing the VCC/GND problem. I would like to clarify that I have no complaints with respect to Synplicity support -- the two issues/suggestions in my earlier post in this thread were both communicated to Synplicity through unconventional channels (such as their newsgroup) and so were not formally tracked as support issues. I appreciate your contributions to this group. Thanks. Thanks also to Peter and Austin and the other vendor 'ambassadors' who make this newsgroup so useful. ----- Product development is sometimes a thankless job. When it works as designed, everyone takes it for granted. When it's broken, even "a little", (or even when it's "user error"), everybody is unhappy. When you change something for a good reason, those that benefit don't realize their good fortune, and those that don't benefit, complain. Either you get support calls, or more happily, the phone doesn't ring at all. But rare indeed is the spontaneous customer compliment "Wow, your product worked great for my application, and I have no complaints. Great work." (Of course I don't consider turning a 2 hr run into a 25 hour run a good thing. Clearly some device-sized RPMs (quite easy to create) belong in the PAR test suite, and the PAR test suite apparently needs some performance regression tests.) (Which reminds me: "There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things. Because the innovator has for enemies all those who have done well under the old conditions, and lukewarm defenders in those who may do well under the new." -- Machiavelli) ----- OK, everybody, Monday is Appreciation Day. Post a success story. Take your FAE to lunch, etc. Go forth and share some good will. Jan Gray, Gray Research LLC ###### Message-ID: <3DB0A12D.8060502@synplicity.com> From: Ken McElvain User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Floorplanner RPM. How to use it? References: <3DB0679F.79D00326@andraka.com> <3DB08AE3.5050909@synplicity.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 62 Date: Sat, 19 Oct 2002 00:04:08 GMT NNTP-Posting-Host: 209.157.48.1 X-Complaints-To: abuse@verio.net X-Trace: sea-read.news.verio.net 1034985848 209.157.48.1 (Sat, 19 Oct 2002 00:04:08 GMT) NNTP-Posting-Date: Sat, 19 Oct 2002 00:04:08 GMT Organization: Verio Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.abs.net!news-out.cwix.com!newsfeed.cwix.com!sjc-peer.news.verio.net!news.verio.net!sea-read.news.verio.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22193 Actually, one of there reasons I follow this new group is to find out about those annoying problems that people suffer with but are too small to bother logging through formal channels. The VDD/GND issue was a perfect example, I'm pretty sure you or someone else posted it here and that's why it got fixed. - Ken Jan Gray wrote: > "Ken McElvain" wrote > >>I belive that the feature you want has just gone out in the 7.2 Beta. >>Why don't you download it and look up what we call a "locked" >>compile point. >> > > Thank you, I will, as time permits. And thanks for addressing the VCC/GND > problem. > > I would like to clarify that I have no complaints with respect to Synplicity > support -- the two issues/suggestions in my earlier post in this thread were > both communicated to Synplicity through unconventional channels (such as > their newsgroup) and so were not formally tracked as support issues. > > I appreciate your contributions to this group. Thanks. Thanks also to > Peter and Austin and the other vendor 'ambassadors' who make this newsgroup > so useful. > > ----- > Product development is sometimes a thankless job. When it works as > designed, everyone takes it for granted. When it's broken, even "a little", > (or even when it's "user error"), everybody is unhappy. When you change > something for a good reason, those that benefit don't realize their good > fortune, and those that don't benefit, complain. > > Either you get support calls, or more happily, the phone doesn't ring at > all. But rare indeed is the spontaneous customer compliment "Wow, your > product worked great for my application, and I have no complaints. Great > work." > > (Of course I don't consider turning a 2 hr run into a 25 hour run a good > thing. Clearly some device-sized RPMs (quite easy to create) belong in the > PAR test suite, and the PAR test suite apparently needs some performance > regression tests.) > > (Which reminds me: "There is nothing more difficult to take in hand, more > perilous to conduct, or more uncertain in its success, than to take the lead > in the introduction of a new order of things. Because the innovator has for > enemies all those who have done well under the old conditions, and lukewarm > defenders in those who may do well under the new." -- Machiavelli) > > ----- > OK, everybody, Monday is Appreciation Day. Post a success story. Take your > FAE to lunch, etc. Go forth and share some good will. > > Jan Gray, Gray Research LLC > > > ###### From: lass Newsgroups: comp.arch.fpga Subject: Re: Floorplanner RPM. How to use it? Date: Fri, 18 Oct 2002 18:21:47 -0600 Organization: Xilinx Lines: 102 Message-ID: <3DB0A59B.66D79DF@xilinx.com> References: <3DB0679F.79D00326@andraka.com> <3DB07978.CFF2C4E4@andraka.com> Reply-To: lass@xilinx.com NNTP-Posting-Host: 149.199.186.86 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Ray Andraka Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!enews.sgi.com!nntp.wetware.com!attdv1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22188 Ray, This is planned to be fixed in our 5.2i release. We might be able to create a tactical patch for you before that, but it sounds like you are not using 5.1i and since no other customers have run into this problem, the current plan is to wait until 5.2i (Feb). Steve Ray Andraka wrote: > I wish that were the case. This is something that broke in 5.1 that causes map > to take 25+ hours to complete where it completed in less than 2 hours on a > machine with half the speed and memory (and paging like crazy on that machine) > using 4.2. It isn't hierarchical composition that is broken, it is RPMs with a > large number of slices (the open case has about 17,000 slices and consists of 50 > identical tiles). In this case, I also ran the tile separately through synplify > for exactly the same reasons you did, and then algorithmically placed the tiles > in the next level up. I've also had the same beef about synplify, but haven't > bothered to complain there. At least Xilinx pretends to listen. > > Do me a favor, run some of your big RPMs through 5.1sp1 and see what it does to > the map time. In my case, it expanded it more than 10x. Then if/when you see > the problem, complain to xilinx loudly about it. You can reference case > 444377. Xilinx appears to be sweeping this one under the rug with a 'no one > else has this problem so perhaps your methodology is flawed' type of response. > The exact quote was: > > "The developers have identified the bottlenecks in map 5.1i sp1. It seems are > sensetive to the 17,000 slice RPM in your design. This was an unforseen use > case which the new map architecture neglects. This is the only design anyone > at Xilinx has seen that uses an RPM this large. > > Therefore, the developers are wondering what problem this RPM solves. Either > you are trying to solve a problem no other designer is trying to solve, or this > is just > a different approach to it. Would you mind explaining what problem you are > solving > with this giant RPM and why you have chosen this method as opposed to some > other method. " > > Likewise, anyone else who uses a similar methodology, please try it out under > 5.1sp1, and if it slows down map, complain to Xilinx about it. Any additional > input to Xilinx to convince them that it isn't an off-the-wall approach would be > welcome (and I would like to be copied on any case, if you care to). > > Jan Gray wrote: > > > "Ray Andraka" wrote > > > ... Of course, Xilinx says they've never heard of people making > > > big RPMs out of smaller ones like this ... > > > > I can only presume that you spoke to someone who didn't know what they were > > talking about. Hierarchical composition is specifically supported by RPMs, > > has been since day one, and is an essential facility. > > > > For example, in March '01, I PAR'd a design that filled a V600E with 60 > > processors. That was 60 instances of a processor RPM (actually 30 and 30 > > mirror-image processor RPMs), each processor RPM a composition of some bus > > interface RPMs and a datapath RPM, each datapath RPM a composition of some > > register RPMs, LUT RAM RPMs, ALU RPMs, addmux RPMs, etc. > > > > That design would have taken ages to process through your favorite synthesis > > tool in one lump. So you synthesize *one* 8x6x4 LUT processor RPM and > > instantiate it as a black box 60 times, RLOC'ing or RLOC_ORIGIN'ing each one > > (instead of making a single, monolithic, monstrous 48x72x4 LUT RPM). > > > > I asked Synplicity to provide a convenient one-step process to synthesize my > > design of 60 copies of an RPM by something like a black-box primitive that > > only expands (and then reuses) one identical submodule of a design (instead > > of wastefully expanding 60 > > topologically-identical-copies-but-with-renamed-synthesized-netnames-submodu > > les-and-their-sub-submodules-etc.) No interest -- so I continued to run > > Synplicity twice, once to synthesize one instance of the processing-element > > submodule (disabling I/O insertion) and once to synthesize the 60 > > instantiations (with the submodule converted to a black box instantiation). > > > > To put it another way, if I mark a module as syn_hier="hard", e.g. "hands > > off, don't optimize into or out of my module, please!", why would two > > instantiations of the module generate two quasi-identical-copies of the > > expanded module in the EDIF, when one shared copy would suffice? > > > > This is also the project where I complained to Synplicity that Synplify > > generates EDIF with unused VCC and GND nets for each of the many, many > > thousands of explicitly technology mapped 1-LUT ALU and addmux RPMs modules > > in my design, causing several minutes of unused-net warnings from MAP (IIRC) > > for each build cycle. > > > > See also http://www.fpgacpu.org/log/mar02.html#020302. > > > > Jan Gray, Gray Research LLC > > -- > --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: <3DB0BBF3.4D6C1856@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: Floorplanner RPM. How to use it? References: <3DB0679F.79D00326@andraka.com> <3DB08AE3.5050909@synplicity.com> <3DB0A12D.8060502@synplicity.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 82 Date: Sat, 19 Oct 2002 01:57:41 GMT NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: news1.east.cox.net 1034992661 68.15.41.165 (Fri, 18 Oct 2002 21:57:41 EDT) NNTP-Posting-Date: Fri, 18 Oct 2002 21:57:41 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!newsfeed.stueberl.de!cox.net!p01!news1.east.cox.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22190 Ken, We do appreciate your presence here even though at times we might not show it. I think most of us who hang here and use the tools have felt the difference. You provide a response that is much better than that provided by tech support. Perhaps you should have your hotline people lurk once in a while too ;-) Ken McElvain wrote: > Actually, one of there reasons I follow this new group is to > find out about those annoying problems that people suffer with > but are too small to bother logging through formal channels. > The VDD/GND issue was a perfect example, I'm pretty sure you > or someone else posted it here and that's why it got fixed. > > - Ken > > Jan Gray wrote: > > > "Ken McElvain" wrote > > > >>I belive that the feature you want has just gone out in the 7.2 Beta. > >>Why don't you download it and look up what we call a "locked" > >>compile point. > >> > > > > Thank you, I will, as time permits. And thanks for addressing the VCC/GND > > problem. > > > > I would like to clarify that I have no complaints with respect to Synplicity > > support -- the two issues/suggestions in my earlier post in this thread were > > both communicated to Synplicity through unconventional channels (such as > > their newsgroup) and so were not formally tracked as support issues. > > > > I appreciate your contributions to this group. Thanks. Thanks also to > > Peter and Austin and the other vendor 'ambassadors' who make this newsgroup > > so useful. > > > > ----- > > Product development is sometimes a thankless job. When it works as > > designed, everyone takes it for granted. When it's broken, even "a little", > > (or even when it's "user error"), everybody is unhappy. When you change > > something for a good reason, those that benefit don't realize their good > > fortune, and those that don't benefit, complain. > > > > Either you get support calls, or more happily, the phone doesn't ring at > > all. But rare indeed is the spontaneous customer compliment "Wow, your > > product worked great for my application, and I have no complaints. Great > > work." > > > > (Of course I don't consider turning a 2 hr run into a 25 hour run a good > > thing. Clearly some device-sized RPMs (quite easy to create) belong in the > > PAR test suite, and the PAR test suite apparently needs some performance > > regression tests.) > > > > (Which reminds me: "There is nothing more difficult to take in hand, more > > perilous to conduct, or more uncertain in its success, than to take the lead > > in the introduction of a new order of things. Because the innovator has for > > enemies all those who have done well under the old conditions, and lukewarm > > defenders in those who may do well under the new." -- Machiavelli) > > > > ----- > > OK, everybody, Monday is Appreciation Day. Post a success story. Take your > > FAE to lunch, etc. Go forth and share some good will. > > > > Jan Gray, Gray Research LLC > > > > > > -- --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: <3DB184BA.1020407@synplicity.com> From: Ken McElvain User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Floorplanner RPM. How to use it? References: <3DB0679F.79D00326@andraka.com> <3DB08AE3.5050909@synplicity.com> <3DB0A12D.8060502@synplicity.com> <3DB0BBF3.4D6C1856@andraka.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 106 Date: Sat, 19 Oct 2002 16:15:01 GMT NNTP-Posting-Host: 209.157.48.1 X-Complaints-To: abuse@verio.net X-Trace: sea-read.news.verio.net 1035044101 209.157.48.1 (Sat, 19 Oct 2002 16:15:01 GMT) NNTP-Posting-Date: Sat, 19 Oct 2002 16:15:01 GMT Organization: Verio Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sjc-peer.news.verio.net!news.verio.net!sea-read.news.verio.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22233 Thanks! Actually there are several of the hotline folks that read the newsgroup, but we limit the number of posters. We have to because we get lots of advanced information and we have to be very sure that we don't announce someone else's new feature for them ;-) BTW, your most recent annoying problem, the unisim library support issue has also been fixed in the 7.2 Beta. The fix is for Virtex and later families. The essence of this problem was that you could either have your VHDL compatible with simulation and have instantiated components treated as black boxes with no timing model, or you could be compatible with Synplify, get timing models for the instantiated components and hence better results. With this fix, you can do both. Ken CTO, Synplicity Inc. Ray Andraka wrote: > Ken, > > We do appreciate your presence here even though at times we might not show it. I > think most of us who hang here and use the tools have felt the difference. You > provide a response that is much better than that provided by tech support. > Perhaps you should have your hotline people lurk once in a while too ;-) > > Ken McElvain wrote: > > >>Actually, one of there reasons I follow this new group is to >>find out about those annoying problems that people suffer with >>but are too small to bother logging through formal channels. >>The VDD/GND issue was a perfect example, I'm pretty sure you >>or someone else posted it here and that's why it got fixed. >> >>- Ken >> >>Jan Gray wrote: >> >> >>>"Ken McElvain" wrote >>> >>> >>>>I belive that the feature you want has just gone out in the 7.2 Beta. >>>>Why don't you download it and look up what we call a "locked" >>>>compile point. >>>> >>>> >>>Thank you, I will, as time permits. And thanks for addressing the VCC/GND >>>problem. >>> >>>I would like to clarify that I have no complaints with respect to Synplicity >>>support -- the two issues/suggestions in my earlier post in this thread were >>>both communicated to Synplicity through unconventional channels (such as >>>their newsgroup) and so were not formally tracked as support issues. >>> >>>I appreciate your contributions to this group. Thanks. Thanks also to >>>Peter and Austin and the other vendor 'ambassadors' who make this newsgroup >>>so useful. >>> >>>----- >>>Product development is sometimes a thankless job. When it works as >>>designed, everyone takes it for granted. When it's broken, even "a little", >>>(or even when it's "user error"), everybody is unhappy. When you change >>>something for a good reason, those that benefit don't realize their good >>>fortune, and those that don't benefit, complain. >>> >>>Either you get support calls, or more happily, the phone doesn't ring at >>>all. But rare indeed is the spontaneous customer compliment "Wow, your >>>product worked great for my application, and I have no complaints. Great >>>work." >>> >>>(Of course I don't consider turning a 2 hr run into a 25 hour run a good >>>thing. Clearly some device-sized RPMs (quite easy to create) belong in the >>>PAR test suite, and the PAR test suite apparently needs some performance >>>regression tests.) >>> >>>(Which reminds me: "There is nothing more difficult to take in hand, more >>>perilous to conduct, or more uncertain in its success, than to take the lead >>>in the introduction of a new order of things. Because the innovator has for >>>enemies all those who have done well under the old conditions, and lukewarm >>>defenders in those who may do well under the new." -- Machiavelli) >>> >>>----- >>>OK, everybody, Monday is Appreciation Day. Post a success story. Take your >>>FAE to lunch, etc. Go forth and share some good will. >>> >>>Jan Gray, Gray Research LLC >>> >>> >>> >>> > > -- > --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: allan_herriman.hates.spam@agilent.com (Allan Herriman) Newsgroups: comp.arch.fpga Subject: Re: Floorplanner RPM. How to use it? Date: Sat, 19 Oct 2002 18:53:17 GMT Organization: Agilent Technologies Lines: 35 Message-ID: <3db1a367.1584538@netnews.agilent.com> References: <3DB0679F.79D00326@andraka.com> <3DB08AE3.5050909@synplicity.com> <3DB0A12D.8060502@synplicity.com> <3DB0BBF3.4D6C1856@andraka.com> <3DB184BA.1020407@synplicity.com> NNTP-Posting-Host: cswreg.cos.agilent.com X-Trace: cswtrans.cos.agilent.com 1035053581 23608 130.29.154.45 (19 Oct 2002 18:53:01 GMT) X-Complaints-To: usenet@cswtrans.cos.agilent.com NNTP-Posting-Date: Sat, 19 Oct 2002 18:53:01 +0000 (UTC) X-Newsreader: Forte Free Agent 1.21/32.243 Cache-Post-Path: cswreg.cos.agilent.com!unknown@ausnadyip45.aus.agilent.com 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!enews.sgi.com!sdd.hp.com!agilent.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22236 On Sat, 19 Oct 2002 16:15:01 GMT, Ken McElvain wrote: >Thanks! Actually there are several of the hotline folks that read the >newsgroup, but we limit the number of posters. Ah, good. I'd like to know what you are doing about the SRL16 inference rule change between 7.0 and 7.1. We have a number of designs here that break in 7.1 and 7.2 because Synplify Pro is inappropriately changing FF into SRL16E. Problem 1 (fixed in 7.2 beta) Some FF with 350MHz clock get converted to SRL16E. SRL16E don't work at 350MHz (in Virtex2). Problem 2 (still outstanding) Some FF with async reset get converted to SRL16E. SRL16E don't have an async reset input, so this is a functional change. (It's that old problem of Synplify trying to be too clever about the meaning of GSR when the startup block is present. If an FPGA has an external reset input (connected to the startup block) then it is *not* correct to assume that GSR is only active during configuration.) Problem 3 (still outstanding) Some FF that were in IOBs get converted to SRL16E. This breaks the I/O timing on the part. Problem 3 is actually the worst one for us, since most of the designs infer I/O FF. I rather liked the 6.x rule that only allowed an RTL FF to be converted to SRL16E when the FF was coded without an async reset or set. Regards, Allan. ###### Message-ID: <3DB2A716.CDA31C91@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: Floorplanner RPM. How to use it? References: <3DB0679F.79D00326@andraka.com> <3DB08AE3.5050909@synplicity.com> <3DB0A12D.8060502@synplicity.com> <3DB0BBF3.4D6C1856@andraka.com> <3DB184BA.1020407@synplicity.com> <3db1a367.1584538@netnews.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: MIPS Technologies (UK) Ltd Cache-Post-Path: mudchute.algor.co.uk!unknown@poplar.algor.co.uk X-Cache: nntpcache 2.4.0b2 (see http://www.nntpcache.org/) Lines: 49 Date: Sun, 20 Oct 2002 13:52:38 +0100 NNTP-Posting-Host: 62.254.210.129 X-Complaints-To: abuse@ntlworld.com X-Trace: newsfep2-win.server.ntli.net 1035118361 62.254.210.129 (Sun, 20 Oct 2002 13:52:41 BST) NNTP-Posting-Date: Sun, 20 Oct 2002 13:52:41 BST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!newsfeed.stueberl.de!newspeer1-gui.server.ntli.net!ntli.net!newsfep2-win.server.ntli.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22229 Allan Herriman wrote: > On Sat, 19 Oct 2002 16:15:01 GMT, Ken McElvain > wrote: > > >Thanks! Actually there are several of the hotline folks that read the > >newsgroup, but we limit the number of posters. > > Ah, good. I'd like to know what you are doing about the SRL16 > inference rule change between 7.0 and 7.1. We have a number of > designs here that break in 7.1 and 7.2 because Synplify Pro is > inappropriately changing FF into SRL16E. > > Problem 1 (fixed in 7.2 beta) Some FF with 350MHz clock get converted > to SRL16E. SRL16E don't work at 350MHz (in Virtex2). > > Problem 2 (still outstanding) Some FF with async reset get converted > to SRL16E. SRL16E don't have an async reset input, so this is a > functional change. > (It's that old problem of Synplify trying to be too clever about the > meaning of GSR when the startup block is present. If an FPGA has an > external reset input (connected to the startup block) then it is *not* > correct to assume that GSR is only active during configuration.) > > Problem 3 (still outstanding) Some FF that were in IOBs get converted > to SRL16E. This breaks the I/O timing on the part. > > Problem 3 is actually the worst one for us, since most of the designs > infer I/O FF. > Does `syn_useiobffs' stop it inferring SRL16Es ? If not this is a killer bug and mucho thanks for the warning as I was just about to make the move from 7.0.2 -> 7.2. > > I rather liked the 6.x rule that only allowed an RTL FF to be > converted to SRL16E when the FF was coded without an async reset or > set. > In fact I can't see how Synplify can legally infer an SRL16(+/-E) for an FF with any sort of set/reset sync or async since the Xilinx primitive doesn't have a reset pin!. IIRC this was actually broken in 6.0beta and I had a I2C module shift reg with sync. clear inferred as an SRL16. Got fixed in 6.1 I think. ###### Message-ID: <3DB2A8A9.E0849BFD@iprimus.com.au> From: Russell X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Floorplanner RPM. How to use it? References: <3DB0679F.79D00326@andraka.com> <3DB07978.CFF2C4E4@andraka.com> <3DB0A59B.66D79DF@xilinx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Original-NNTP-Posting-Host: 210.50.118.164 Organization: iPrimus Customer - reports relating to abuse should be sent to abuse@iprimus.com.au Lines: 31 X-Original-NNTP-Posting-Host: 127.0.0.1 Date: Sun, 20 Oct 2002 22:59:21 +1000 NNTP-Posting-Host: 203.134.67.67 X-Complaints-To: news@primus.ca X-Trace: news.primus.ca 1035118388 203.134.67.67 (Sun, 20 Oct 2002 08:53:08 EDT) NNTP-Posting-Date: Sun, 20 Oct 2002 08:53:08 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed1.cidera.com!Cidera!news.maxwell.syr.edu!newsfeed-east.nntpserver.com!nntpserver.com!feed.cgocable.net!feed.tor.primus.ca!news.primus.ca!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22235 I'll be doing designs with multiple large RPMs too. Are the netlists hierarchial in 5.1? Efficient handling of hand-routed RPMs in a hierarchial netlist is what i consider to be *the* most important feature. It should be easy to build low-level RPMs and link them together to make larger RPMs, until you've done the whole project from the bottom up. In the end, your whole project is an RPM, which you could re-use as a library component. It's not hard to see that anyone could be building mega-chip designs from these components in just a few minutes. It's this sort of capability i'd aim for in an open source tool. lass wrote: > > Ray, > > This is planned to be fixed in our 5.2i release. We might be able to create a tactical > patch for you before that, but it sounds like you are not using 5.1i and since no other > customers have run into this problem, the current plan is to wait until 5.2i (Feb). > > Steve > > Ray Andraka wrote: > > > I wish that were the case. This is something that broke in 5.1 that causes map > > to take 25+ hours to complete where it completed in less than 2 hours on a > > machine with half the speed and memory (and paging like crazy on that machine) > > using 4.2... ###### From: allan_herriman.hates.spam@agilent.com (Allan Herriman) Newsgroups: comp.arch.fpga Subject: Re: Floorplanner RPM. How to use it? Date: Mon, 21 Oct 2002 05:49:16 GMT Organization: Agilent Technologies Lines: 66 Message-ID: <3db39198.879775@netnews.agilent.com> References: <3DB0679F.79D00326@andraka.com> <3DB08AE3.5050909@synplicity.com> <3DB0A12D.8060502@synplicity.com> <3DB0BBF3.4D6C1856@andraka.com> <3DB184BA.1020407@synplicity.com> <3db1a367.1584538@netnews.agilent.com> <3DB2A716.CDA31C91@algor.co.uk> NNTP-Posting-Host: cswreg.cos.agilent.com X-Trace: cswtrans.cos.agilent.com 1035179357 8379 130.29.154.45 (21 Oct 2002 05:49:17 GMT) X-Complaints-To: usenet@cswtrans.cos.agilent.com NNTP-Posting-Date: Mon, 21 Oct 2002 05:49:17 +0000 (UTC) X-Newsreader: Forte Free Agent 1.21/32.243 Cache-Post-Path: cswreg.cos.agilent.com!unknown@hpiw0398.aus.agilent.com 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!cyclone.bc.net!newsfeed.stanford.edu!news.isc.org!agilent.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22267 On Sun, 20 Oct 2002 13:52:38 +0100, Rick Filipkiewicz wrote: > > >Allan Herriman wrote: > >> On Sat, 19 Oct 2002 16:15:01 GMT, Ken McElvain >> wrote: >> >> >Thanks! Actually there are several of the hotline folks that read the >> >newsgroup, but we limit the number of posters. >> >> Ah, good. I'd like to know what you are doing about the SRL16 >> inference rule change between 7.0 and 7.1. We have a number of >> designs here that break in 7.1 and 7.2 because Synplify Pro is >> inappropriately changing FF into SRL16E. >> >> Problem 1 (fixed in 7.2 beta) Some FF with 350MHz clock get converted >> to SRL16E. SRL16E don't work at 350MHz (in Virtex2). >> >> Problem 2 (still outstanding) Some FF with async reset get converted >> to SRL16E. SRL16E don't have an async reset input, so this is a >> functional change. >> (It's that old problem of Synplify trying to be too clever about the >> meaning of GSR when the startup block is present. If an FPGA has an >> external reset input (connected to the startup block) then it is *not* >> correct to assume that GSR is only active during configuration.) >> >> Problem 3 (still outstanding) Some FF that were in IOBs get converted >> to SRL16E. This breaks the I/O timing on the part. >> >> Problem 3 is actually the worst one for us, since most of the designs >> infer I/O FF. >> > >Does `syn_useiobffs' stop it inferring SRL16Es ? If not this is a killer >bug and mucho thanks for the warning as I was just about to make the move >from 7.0.2 -> 7.2. Haven't tried that one. This is legacy code that doesn't have many tool specific attributes. In general, I don't like littering my code with attributes just to get reasonable behaviour from the synthesiser, particularly when earlier versions of the same synthesiser did the right thing. But I guess it all hinges on the meaning of "reasonable" ... As we saw with the tristate buffer push through bug, tool vendors can have a rather odd view of what customers want from their tools. >> >> I rather liked the 6.x rule that only allowed an RTL FF to be >> converted to SRL16E when the FF was coded without an async reset or >> set. >> > >In fact I can't see how Synplify can legally infer an SRL16(+/-E) for an FF >with any sort of set/reset sync or async since the Xilinx primitive doesn't >have a reset pin!. IIRC this was actually broken in 6.0beta and I had a I2C >module shift reg with sync. clear inferred as an SRL16. Got fixed in 6.1 I >think. Well, it seems to be broken again. Regards, Allan. ###### From: allan_herriman.hates.spam@agilent.com (Allan Herriman) Newsgroups: comp.arch.fpga Subject: Re: Floorplanner RPM. How to use it? Date: Mon, 21 Oct 2002 09:18:07 GMT Organization: Agilent Technologies Lines: 77 Message-ID: <3db3c4cd.10160019@netnews.agilent.com> References: <3DB0679F.79D00326@andraka.com> <3DB08AE3.5050909@synplicity.com> <3DB0A12D.8060502@synplicity.com> <3DB0BBF3.4D6C1856@andraka.com> <3DB184BA.1020407@synplicity.com> <3db1a367.1584538@netnews.agilent.com> <3DB2A716.CDA31C91@algor.co.uk> <3db39198.879775@netnews.agilent.com> NNTP-Posting-Host: cswreg.cos.agilent.com X-Trace: cswtrans.cos.agilent.com 1035191889 13514 130.29.154.45 (21 Oct 2002 09:18:09 GMT) X-Complaints-To: usenet@cswtrans.cos.agilent.com NNTP-Posting-Date: Mon, 21 Oct 2002 09:18:09 +0000 (UTC) X-Newsreader: Forte Free Agent 1.21/32.243 Cache-Post-Path: cswreg.cos.agilent.com!unknown@hpiw0398.aus.agilent.com 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!enews.sgi.com!sdd.hp.com!agilent.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22270 On Mon, 21 Oct 2002 05:49:16 GMT, allan_herriman.hates.spam@agilent.com (Allan Herriman) wrote: >On Sun, 20 Oct 2002 13:52:38 +0100, Rick Filipkiewicz > wrote: > >> >> >>Allan Herriman wrote: >> >>> On Sat, 19 Oct 2002 16:15:01 GMT, Ken McElvain >>> wrote: >>> >>> >Thanks! Actually there are several of the hotline folks that read the >>> >newsgroup, but we limit the number of posters. >>> >>> Ah, good. I'd like to know what you are doing about the SRL16 >>> inference rule change between 7.0 and 7.1. We have a number of >>> designs here that break in 7.1 and 7.2 because Synplify Pro is >>> inappropriately changing FF into SRL16E. >>> >>> Problem 1 (fixed in 7.2 beta) Some FF with 350MHz clock get converted >>> to SRL16E. SRL16E don't work at 350MHz (in Virtex2). >>> >>> Problem 2 (still outstanding) Some FF with async reset get converted >>> to SRL16E. SRL16E don't have an async reset input, so this is a >>> functional change. >>> (It's that old problem of Synplify trying to be too clever about the >>> meaning of GSR when the startup block is present. If an FPGA has an >>> external reset input (connected to the startup block) then it is *not* >>> correct to assume that GSR is only active during configuration.) >>> >>> Problem 3 (still outstanding) Some FF that were in IOBs get converted >>> to SRL16E. This breaks the I/O timing on the part. >>> >>> Problem 3 is actually the worst one for us, since most of the designs >>> infer I/O FF. >>> >> >>Does `syn_useiobffs' stop it inferring SRL16Es ? If not this is a killer >>bug and mucho thanks for the warning as I was just about to make the move >>from 7.0.2 -> 7.2. > >Haven't tried that one. This is legacy code that doesn't have many >tool specific attributes. >In general, I don't like littering my code with attributes just to get >reasonable behaviour from the synthesiser, particularly when earlier >versions of the same synthesiser did the right thing. >But I guess it all hinges on the meaning of "reasonable" ... > >As we saw with the tristate buffer push through bug, tool vendors can >have a rather odd view of what customers want from their tools. > >>> >>> I rather liked the 6.x rule that only allowed an RTL FF to be >>> converted to SRL16E when the FF was coded without an async reset or >>> set. >>> >> >>In fact I can't see how Synplify can legally infer an SRL16(+/-E) for an FF >>with any sort of set/reset sync or async since the Xilinx primitive doesn't >>have a reset pin!. IIRC this was actually broken in 6.0beta and I had a I2C >>module shift reg with sync. clear inferred as an SRL16. Got fixed in 6.1 I >>think. > >Well, it seems to be broken again. Minor clarification: If the GSR net is connected to a ROC block, then the synthesiser can know that GSR is only active during configuration, and therefore it is safe to convert a FF (with async set or reset) into an SRL16(E). But the problem I was seeing had to do with an async reset net that had an external connection, therefore no conversion is possible. Regards, Allan. ###### From: "Francisco Rodriguez" Newsgroups: comp.arch.fpga Subject: Re: Floorplanner RPM. How to use it? Date: Mon, 21 Oct 2002 12:22:51 +0200 Organization: U.P.V. Lines: 84 Message-ID: References: <3DB0679F.79D00326@andraka.com> NNTP-Posting-Host: prodrig.disca.upv.es X-Trace: polaris.cc.upv.es 1035194710 7500 158.42.53.4 (21 Oct 2002 10:05:10 GMT) X-Complaints-To: newsmaster@upv.es NNTP-Posting-Date: 21 Oct 2002 10:05:10 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!fr.usenet-edu.net!usenet-edu.net!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.mathworks.com!arclight.uoregon.edu!logbridge.uoregon.edu!news.rediris.es!news.uv.es!news.upv.es!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22264 Thanks for your clarification Ray. It is now clear to me that Floorplan RPM is completely useless in my particular case. I want to apply different synthesis goals to each part (area for the RPM, speed for the rest) and I see no way to achieve this into a single, flat design. I already knew i could RLOC the source directly, but I was reluctant as I'm not comfortable designing at such low level. I'll try to use the post-translate VHDL equivalent to figure out how to "synthesize" my original design into RLOCable VHDL. I would also to try the FPGA Editor way, but before this I would like to hear more comments about timing analysis and simulation difficulties that can arise. Reading the tool manual, it clearly states that the hard macro saves place info, not routing (timing is not guaranteed). So I _assume_ routing is still generated and analyzed every time PAR is run. Am i right here? Regards Francisco "Ray Andraka" escribió en el mensaje news:3DB0679F.79D00326@andraka.com... > If it was created in the floorplanner, you are restricted to using it in > that design, at least as of v4.2i. You can export it as a UCF file, which > essentially puts LOCs on all the pieces, so you could bring it into > another design only if the device is the same size and the hierarchical > names are unchanged. Not all that useful, I know. The problem with the > floorplanner (well, one of many problems actually) is that it is not > hierarchical: it works on a flat representation of your design, so you > wind up having to floorplan each copy of multiple identical instances > instead of doing it once unless you do the floorplanning in your source. > You can also create hard macros using the FPGA editor and bring them in as > black boxes into your source. I don't like doing that because it makes > simulation and timing analysis difficult. > > We put RLOCs directly into our VHDL so that we end up with placed RPMs > that can be used in any design without having to go through floorplanning > every time. In that case, you just instantiate the RPM as a component in > the HDL code (and stick an RLOC on that component if it is forming a > larger RPM). Of course, Xilinx says they've never heard of people making > big RPMs out of smaller ones like this, and the 5.1 tools barf on big > RPMs...but that is beside the point. > > Francisco Rodriguez wrote: > > > Hello all > > > > I'm working with Xilinx ISE 4.1 tools. I have a small design manually > > floorplanned and have created an RPM with all the logic, but > > without IOBs or BUFGs. > > > > Now I want to use this RPM as a design black block in a larger design. > > How do I instantiate it into my VHDL model? > > > > Or am I completely wrong on the use of RPMs? > > > > Regards > > Francisco > > ==================================================== > > Francisco Rodriguez Ballester (prodrig@disca.upv.es) > > Dept. DISCA, EUI - Univ. Politecnica de Valencia > > c/Camino de Vera s/n, E-46022, VALENCIA (SPAIN) > > tlf: +(34) 96 387 75 77 - fax: +(34) 96 387 75 79 > > ==================================================== > > -- > --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: <3DB3E4A9.C2E2F36@iprimus.com.au> From: Russell X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Floorplanner RPM. How to use it? References: <3DB0679F.79D00326@andraka.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Original-NNTP-Posting-Host: 210.50.10.90 Organization: iPrimus Customer - reports relating to abuse should be sent to abuse@iprimus.com.au Lines: 27 X-Original-NNTP-Posting-Host: 127.0.0.1 Date: Mon, 21 Oct 2002 21:27:37 +1000 NNTP-Posting-Host: 203.134.67.67 X-Complaints-To: news@primus.ca X-Trace: news.primus.ca 1035199278 203.134.67.67 (Mon, 21 Oct 2002 07:21:18 EDT) NNTP-Posting-Date: Mon, 21 Oct 2002 07:21:18 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!solnet.ch!solnet.ch!newsfeed.freenet.de!newsfeed.news2me.com!feed.cgocable.net!feed.tor.primus.ca!news.primus.ca!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22260 Ray Andraka wrote: > > If it was created in the floorplanner, you are restricted to using it in > that design, at least as of v4.2i. You can export it as a UCF file, which > essentially puts LOCs on all the pieces, so you could bring it into > another design only if the device is the same size and the hierarchical > names are unchanged. Not all that useful, I know. The problem with the > floorplanner (well, one of many problems actually) is that it is not > hierarchical: it works on a flat representation of your design, so you > wind up having to floorplan each copy of multiple identical instances > instead of doing it once unless you do the floorplanning in your source. > You can also create hard macros using the FPGA editor and bring them in as > black boxes into your source. I don't like doing that because it makes > simulation and timing analysis difficult. > > We put RLOCs directly into our VHDL so that we end up with placed RPMs > that can be used in any design without having to go through floorplanning > every time. In that case, you just instantiate the RPM as a component in > the HDL code (and stick an RLOC on that component if it is forming a > larger RPM)... Hi, When you make an RPM by putting the constraints in the VHDL source, can you position the RPM on the floorplanner with the mouse, or do you need to rerun the tools a few times and iteratively change the position of that RPM by changing a constraint in the source in order to position various RPM blocks together? ###### Message-ID: <3DB3EAFD.F2E44BF5@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: Floorplanner RPM. How to use it? References: <3DB0679F.79D00326@andraka.com> <3DB08AE3.5050909@synplicity.com> <3DB0A12D.8060502@synplicity.com> <3DB0BBF3.4D6C1856@andraka.com> <3DB184BA.1020407@synplicity.com> <3db1a367.1584538@netnews.agilent.com> <3DB2A716.CDA31C91@algor.co.uk> <3db39198.879775@netnews.agilent.com> <3db3c4cd.10160019@netnews.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 112 Date: Mon, 21 Oct 2002 11:55:05 GMT NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: news1.east.cox.net 1035201305 68.15.41.165 (Mon, 21 Oct 2002 07:55:05 EDT) NNTP-Posting-Date: Mon, 21 Oct 2002 07:55:05 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!sjc70.webusenet.com!news.webusenet.com!cox.net!p01!news1.east.cox.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22254 First, I'll admit that I haven't upgraded to 7.2 yet, We're using 7.03 until we get these few projects out the door because we know it is stable and we know the quirks in it. 7.1 broke a bunch of our things, and with the schedule we didn't have too much time to mess with it. Now the schedule is tighter, and I don't have the slack time to learn the quirks in another tool (got enough tool debug going on with the recent Xilinx releases...uh, 'escapes' as it is). For the SRL16's, We generally try to put the last clock of delay into a FF because of the relatively long clock->Q of the SRL16. I can't have that flip-flop getting sucked into the SRL16, even if such modification is controlled by the clock period. We generally turn the clock to 0 in synplify to keep it from duplicating stuff that is RLOC'd in aggressive designs. That works fine as long as the logic between registers is reasonably simple (eg., single level of logic), but it also means that I don't want ff's I intend to follow an SRL16 getting absorbed into the SRL16. I also don't want the SRL16 inference automatically putting a flip-flop at the end if the SRL16 address is dynamic. For static SRL16 address, automatic inference of a flip-flop after *EACH* SRL16, even when there are several SRL16's in a chain is a nice feature. I believe 7.03 does that just for the last SRL16 in a chain. Allan Herriman wrote: > On Mon, 21 Oct 2002 05:49:16 GMT, > allan_herriman.hates.spam@agilent.com (Allan Herriman) wrote: > > >On Sun, 20 Oct 2002 13:52:38 +0100, Rick Filipkiewicz > > wrote: > > > >> > >> > >>Allan Herriman wrote: > >> > >>> On Sat, 19 Oct 2002 16:15:01 GMT, Ken McElvain > >>> wrote: > >>> > >>> >Thanks! Actually there are several of the hotline folks that read the > >>> >newsgroup, but we limit the number of posters. > >>> > >>> Ah, good. I'd like to know what you are doing about the SRL16 > >>> inference rule change between 7.0 and 7.1. We have a number of > >>> designs here that break in 7.1 and 7.2 because Synplify Pro is > >>> inappropriately changing FF into SRL16E. > >>> > >>> Problem 1 (fixed in 7.2 beta) Some FF with 350MHz clock get converted > >>> to SRL16E. SRL16E don't work at 350MHz (in Virtex2). > >>> > >>> Problem 2 (still outstanding) Some FF with async reset get converted > >>> to SRL16E. SRL16E don't have an async reset input, so this is a > >>> functional change. > >>> (It's that old problem of Synplify trying to be too clever about the > >>> meaning of GSR when the startup block is present. If an FPGA has an > >>> external reset input (connected to the startup block) then it is *not* > >>> correct to assume that GSR is only active during configuration.) > >>> > >>> Problem 3 (still outstanding) Some FF that were in IOBs get converted > >>> to SRL16E. This breaks the I/O timing on the part. > >>> > >>> Problem 3 is actually the worst one for us, since most of the designs > >>> infer I/O FF. > >>> > >> > >>Does `syn_useiobffs' stop it inferring SRL16Es ? If not this is a killer > >>bug and mucho thanks for the warning as I was just about to make the move > >>from 7.0.2 -> 7.2. > > > >Haven't tried that one. This is legacy code that doesn't have many > >tool specific attributes. > >In general, I don't like littering my code with attributes just to get > >reasonable behaviour from the synthesiser, particularly when earlier > >versions of the same synthesiser did the right thing. > >But I guess it all hinges on the meaning of "reasonable" ... > > > >As we saw with the tristate buffer push through bug, tool vendors can > >have a rather odd view of what customers want from their tools. > > > >>> > >>> I rather liked the 6.x rule that only allowed an RTL FF to be > >>> converted to SRL16E when the FF was coded without an async reset or > >>> set. > >>> > >> > >>In fact I can't see how Synplify can legally infer an SRL16(+/-E) for an FF > >>with any sort of set/reset sync or async since the Xilinx primitive doesn't > >>have a reset pin!. IIRC this was actually broken in 6.0beta and I had a I2C > >>module shift reg with sync. clear inferred as an SRL16. Got fixed in 6.1 I > >>think. > > > >Well, it seems to be broken again. > > Minor clarification: If the GSR net is connected to a ROC block, then > the synthesiser can know that GSR is only active during configuration, > and therefore it is safe to convert a FF (with async set or reset) > into an SRL16(E). > > But the problem I was seeing had to do with an async reset net that > had an external connection, therefore no conversion is possible. > > Regards, > Allan. -- --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: <3DB3ED14.DFB4BED4@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: Floorplanner RPM. How to use it? References: <3DB0679F.79D00326@andraka.com> <3DB3E4A9.C2E2F36@iprimus.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 39 Date: Mon, 21 Oct 2002 12:04:00 GMT NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: news1.east.cox.net 1035201840 68.15.41.165 (Mon, 21 Oct 2002 08:04:00 EDT) NNTP-Posting-Date: Mon, 21 Oct 2002 08:04:00 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!feedme.news.mediaways.net!newsfeed.icl.net!newsfeed.fjserv.net!logbridge.uoregon.edu!nntp-relay.ihug.net!ihug.co.nz!west.cox.net!cox.net!p01!news1.east.cox.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22253 Well, you are supposed to be able to pick up the RPM from the hierarchy browser and place it with the floorplanner, but the floorplanner is broken in 4.x. In order to place RPMs, you need to run through automatic place and route, then open the floorplanner, constrain the RPMs from placement, unbind and rebind each RPM, then you can move it around. It is a very awkward and time consuming workaround that does not work for densely populated designs with large RPMs. Do us all a favor and complain to XIlinx about the broken floorplanner. There is a general attitude there that floorplanning is only used by a few experts, and so it is the neglected stepchild. The fact of the matter is that floorplanning is crucial to any form of modular design capability, and until they recognize it they probably will not get a reasonable modular design flow. With the size of current devices, modular design is the only way to achieve reasonable design times. Right now, big hierarchical design with big rpms is the easiest way to achieve a semblance of modular design in the tools. I have not tried out the floorplanner in the 5.1 software yet because of the long map times associated with big RPMs. I understand that a patch is forthcoming for that bug if if bites you. Russell wrote: > RHi, > When you make an RPM by putting the constraints in the VHDL source, > can you position the RPM on the floorplanner with the mouse, or do > you need to rerun the tools a few times and iteratively change the > position of that RPM by changing a constraint in the source in order > to position various RPM blocks together? -- --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: <3DB3EEEE.86FB7DD4@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: Floorplanner RPM. How to use it? References: <3DB0679F.79D00326@andraka.com> <3DB07978.CFF2C4E4@andraka.com> <3DB0A59B.66D79DF@xilinx.com> <3DB2A8A9.E0849BFD@iprimus.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 54 Date: Mon, 21 Oct 2002 12:11:54 GMT NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: news1.east.cox.net 1035202314 68.15.41.165 (Mon, 21 Oct 2002 08:11:54 EDT) NNTP-Posting-Date: Mon, 21 Oct 2002 08:11:54 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.stueberl.de!cox.net!p01!news1.east.cox.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22255 The edif netlists are hierarchical, and have been since day 1. The problem is Xilinx views the world as flat, so it flattens everything. Until thier tools view the designs as hierarchical rather than flattened, I think they will continue to have problems with large designs and RPMs, and will probably not be able to achieve a reasonable modular flow. We currently work around the shortcomings of the flat world society in EDA land by building RPMs hierarchically in the source, which leads to big placed RPMs, which in turn broke the 5.1 Xilinx tools as mentioned earlier in this thread. Russell wrote: > I'll be doing designs with multiple large RPMs too. Are the netlists > hierarchial in 5.1? > > Efficient handling of hand-routed RPMs in a hierarchial netlist > is what i consider to be *the* most important feature. It should > be easy to build low-level RPMs and link them together to make > larger RPMs, until you've done the whole project from the bottom > up. > > In the end, your whole project is an RPM, which you could re-use > as a library component. It's not hard to see that anyone could > be building mega-chip designs from these components in just a > few minutes. It's this sort of capability i'd aim for in an > open source tool. > > lass wrote: > > > > Ray, > > > > This is planned to be fixed in our 5.2i release. We might be able to create a tactical > > patch for you before that, but it sounds like you are not using 5.1i and since no other > > customers have run into this problem, the current plan is to wait until 5.2i (Feb). > > > > Steve > > > > Ray Andraka wrote: > > > > > I wish that were the case. This is something that broke in 5.1 that causes map > > > to take 25+ hours to complete where it completed in less than 2 hours on a > > > machine with half the speed and memory (and paging like crazy on that machine) > > > using 4.2... -- --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: <3DB4234C.6050302@synplicity.com> From: Ken McElvain User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Floorplanner RPM. How to use it? References: <3DB0679F.79D00326@andraka.com> <3DB3E4A9.C2E2F36@iprimus.com.au> <3DB3ED14.DFB4BED4@andraka.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 60 Date: Mon, 21 Oct 2002 15:56:06 GMT NNTP-Posting-Host: 209.157.48.1 X-Complaints-To: abuse@verio.net X-Trace: sea-read.news.verio.net 1035215766 209.157.48.1 (Mon, 21 Oct 2002 15:56:06 GMT) NNTP-Posting-Date: Mon, 21 Oct 2002 15:56:06 GMT Organization: Verio Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.mathworks.com!dfw-peer!news.verio.net!sea-read.news.verio.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22257 Ray Andraka wrote: > Well, you are supposed to be able to pick up the RPM from the hierarchy browser > and place it with the floorplanner, but the floorplanner is broken in 4.x. In > order to place RPMs, you need to run through automatic place and route, then > open the floorplanner, constrain the RPMs from placement, unbind and rebind each > RPM, then you can move it around. It is a very awkward and time consuming > workaround that does not work for densely populated designs with large RPMs. Do > us all a favor and complain to XIlinx about the broken floorplanner. There is a > general attitude there that floorplanning is only used by a few experts, and so > it is the neglected stepchild. The fact of the matter is that floorplanning is > crucial to any form of modular design capability, and until they recognize it > they probably will not get a reasonable modular design flow. With the size of > current devices, modular design is the only way to achieve reasonable design > times. Right now, big hierarchical design with big rpms is the easiest way to Actually, if you use the new MultiPoint features in Synplify Pro 7.2 feeding into the area group based P&R incremental flow, you get very good iteration times for large designs. The whole flow becomes incremental to the level of the area groups. Synplify Pro automatically detects differences in the source code (not file dates, that is too crude - especially for VHDL package file changes) that affect each area group and only recompiles as needed. - Ken > achieve a semblance of modular design in the tools. I have not tried out the > floorplanner in the 5.1 software yet because of the long map times associated > with big RPMs. I understand that a patch is forthcoming for that bug if if > bites you. > > Russell wrote: > > >>RHi, >>When you make an RPM by putting the constraints in the VHDL source, >>can you position the RPM on the floorplanner with the mouse, or do >>you need to rerun the tools a few times and iteratively change the >>position of that RPM by changing a constraint in the source in order >>to position various RPM blocks together? >> > > -- > --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: <3DB49E72.10800@synplicity.com> From: Ken McElvain User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Floorplanner RPM. How to use it? References: <3DB0679F.79D00326@andraka.com> <3DB08AE3.5050909@synplicity.com> <3DB0A12D.8060502@synplicity.com> <3DB0BBF3.4D6C1856@andraka.com> <3DB184BA.1020407@synplicity.com> <3db1a367.1584538@netnews.agilent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 57 Date: Tue, 22 Oct 2002 00:41:31 GMT NNTP-Posting-Host: 209.157.48.1 X-Complaints-To: abuse@verio.net X-Trace: sea-read.news.verio.net 1035247291 209.157.48.1 (Tue, 22 Oct 2002 00:41:31 GMT) NNTP-Posting-Date: Tue, 22 Oct 2002 00:41:31 GMT Organization: Verio Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!proxad.net!newsfeed.media.kyoto-u.ac.jp!sjc-peer.news.verio.net!news.verio.net!sea-read.news.verio.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22298 Allan Herriman wrote: > On Sat, 19 Oct 2002 16:15:01 GMT, Ken McElvain > wrote: > > >>Thanks! Actually there are several of the hotline folks that read the >>newsgroup, but we limit the number of posters. >> > > Ah, good. I'd like to know what you are doing about the SRL16 > inference rule change between 7.0 and 7.1. We have a number of > designs here that break in 7.1 and 7.2 because Synplify Pro is > inappropriately changing FF into SRL16E. > > Problem 1 (fixed in 7.2 beta) Some FF with 350MHz clock get converted > to SRL16E. SRL16E don't work at 350MHz (in Virtex2). > > Problem 2 (still outstanding) Some FF with async reset get converted > to SRL16E. SRL16E don't have an async reset input, so this is a > functional change. > (It's that old problem of Synplify trying to be too clever about the > meaning of GSR when the startup block is present. If an FPGA has an > external reset input (connected to the startup block) then it is *not* > correct to assume that GSR is only active during configuration.) Sorry, this was a bug in the 7.2 beta1 . I understand that it has already been fixed in the current 7.2 beta2. We usually go through 2 rounds of beta before production release. > > Problem 3 (still outstanding) Some FF that were in IOBs get converted > to SRL16E. This breaks the I/O timing on the part. We would love a small test case (or any test case). Our test cases appear to work properly. We are not supposed to be sucking in flip flops connected to I/Os. > > > Problem 3 is actually the worst one for us, since most of the designs > infer I/O FF. > > I rather liked the 6.x rule that only allowed an RTL FF to be > converted to SRL16E when the FF was coded without an async reset or > set. > > Regards, > Allan. > ###### From: allan_herriman.hates.spam@agilent.com (Allan Herriman) Newsgroups: comp.arch.fpga Subject: Re: Floorplanner RPM. How to use it? Date: Tue, 22 Oct 2002 06:31:51 GMT Organization: Agilent Technologies Lines: 60 Message-ID: <3db4ed50.86066266@netnews.agilent.com> References: <3DB0679F.79D00326@andraka.com> <3DB08AE3.5050909@synplicity.com> <3DB0A12D.8060502@synplicity.com> <3DB0BBF3.4D6C1856@andraka.com> <3DB184BA.1020407@synplicity.com> <3db1a367.1584538@netnews.agilent.com> <3DB49E72.10800@synplicity.com> NNTP-Posting-Host: cswreg.cos.agilent.com X-Trace: cswtrans.cos.agilent.com 1035268311 11449 130.29.154.45 (22 Oct 2002 06:31:51 GMT) X-Complaints-To: usenet@cswtrans.cos.agilent.com NNTP-Posting-Date: Tue, 22 Oct 2002 06:31:51 +0000 (UTC) X-Newsreader: Forte Free Agent 1.21/32.243 Cache-Post-Path: cswreg.cos.agilent.com!unknown@hpiw0398.aus.agilent.com 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!enews.sgi.com!sdd.hp.com!agilent.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22309 On Tue, 22 Oct 2002 00:41:31 GMT, Ken McElvain wrote: > > >Allan Herriman wrote: > >> On Sat, 19 Oct 2002 16:15:01 GMT, Ken McElvain >> wrote: >> >> >>>Thanks! Actually there are several of the hotline folks that read the >>>newsgroup, but we limit the number of posters. >>> >> >> Ah, good. I'd like to know what you are doing about the SRL16 >> inference rule change between 7.0 and 7.1. We have a number of >> designs here that break in 7.1 and 7.2 because Synplify Pro is >> inappropriately changing FF into SRL16E. >> >> Problem 1 (fixed in 7.2 beta) Some FF with 350MHz clock get converted >> to SRL16E. SRL16E don't work at 350MHz (in Virtex2). >> >> Problem 2 (still outstanding) Some FF with async reset get converted >> to SRL16E. SRL16E don't have an async reset input, so this is a >> functional change. >> (It's that old problem of Synplify trying to be too clever about the >> meaning of GSR when the startup block is present. If an FPGA has an >> external reset input (connected to the startup block) then it is *not* >> correct to assume that GSR is only active during configuration.) > > >Sorry, this was a bug in the 7.2 beta1 . I understand that it has >already been fixed in the current 7.2 beta2. We usually go through >2 rounds of beta before production release. Different bug. This one is present in 7.1.0, 7.1.1, 7.2.0 beta 1 and 7.2.0 beta 2. >> >> Problem 3 (still outstanding) Some FF that were in IOBs get converted >> to SRL16E. This breaks the I/O timing on the part. > > >We would love a small test case (or any test case). Our test cases >appear to work properly. We are not supposed to be sucking in flip >flops connected to I/Os. Looks like it's going to be a large test case, as this one only seems to happen on a full design. Oddly, on one 64 bit bus, only about half the flip flops are affected in this way. I can not spot anything in the source code that would cause individual bits in that bus to be treated differently. I have been contacted by Synplicity support about sending a test case. We are contacting the legal people here, as we're a bit nervous about giving away the full source for a chip. Regards, Allan. ###### From: hmurray@suespammers.org (Hal Murray) Newsgroups: comp.arch.fpga Subject: Re: Floorplanner RPM. How to use it? Date: Tue, 22 Oct 2002 07:24:58 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: <3DB0679F.79D00326@andraka.com> <3DB08AE3.5050909@synplicity.com> <3DB0A12D.8060502@synplicity.com> <3DB0BBF3.4D6C1856@andraka.com> <3DB184BA.1020407@synplicity.com> <3db1a367.1584538@netnews.agilent.com> <3DB2A716.CDA31C91@algor.co.uk> <3db39198.879775@netnews.agilent.com> <3db3c4cd.10160019@netnews.agilent.com> <3DB3EAFD.F2E44BF5@andraka.com> X-Complaints-To: abuse@supernews.com Lines: 28 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!fr.usenet-edu.net!usenet-edu.net!freenix!sn-xit-05!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray Xref: chonsp.franklin.ch comp.arch.fpga:22314 >For the SRL16's, We generally try to put the last clock of delay into a FF >because of the relatively long clock->Q of the SRL16. I can't have that >flip-flop getting sucked into the SRL16, even if such modification is controlled >by the clock period. We generally turn the clock to 0 in synplify to keep it >from duplicating stuff that is RLOC'd in aggressive designs. That works fine as >long as the logic between registers is reasonably simple (eg., single level of >logic), but it also means that I don't want ff's I intend to follow an SRL16 >getting absorbed into the SRL16. I also don't want the SRL16 inference >automatically putting a flip-flop at the end if the SRL16 address is dynamic. >For static SRL16 address, automatic inference of a flip-flop after *EACH* SRL16, >even when there are several SRL16's in a chain is a nice feature. I believe 7.03 >does that just for the last SRL16 in a chain. Is it reasonable to expect a compiler to be able to do-the-right-thing in all cases like this? Or in most of them? Or is this a good example to show that we need some way to annote/supplement the source code with hints? Or should we just make library packages that instantiate what we really want whenever we need it? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam. ###### Message-ID: <3db534cc$0$18869$afc38c87@news.optusnet.com.au> From: hamish@cloud.net.au Subject: Re: Floorplanner RPM. How to use it? Newsgroups: comp.arch.fpga References: <3DB0679F.79D00326@andraka.com> <3DB08AE3.5050909@synplicity.com> <3DB0A12D.8060502@synplicity.com> <3DB0BBF3.4D6C1856@andraka.com> <3DB184BA.1020407@synplicity.com> <3db1a367.1584538@netnews.agilent.com> <3DB2A716.CDA31C91@algor.co.uk> User-Agent: tin/1.5.14-20020917 ("Chop Suey!") (UNIX) (Linux/2.2.18 (i586)) Date: 22 Oct 2002 11:21:48 GMT Lines: 18 NNTP-Posting-Host: 211.28.158.161 X-Trace: 1035285708 18869 211.28.158.161 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!cyclone.bc.net!newsfeed.media.kyoto-u.ac.jp!snewsf0.syd.ops.aspac.uu.net!news1.optus.net.au!optus!spool01.syd.optusnet.com.au!spool.optusnet.com.au!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22404 Rick Filipkiewicz wrote: >> Problem 3 (still outstanding) Some FF that were in IOBs get converted >> to SRL16E. This breaks the I/O timing on the part. > > Does `syn_useiobffs' stop it inferring SRL16Es ? If not this is a killer > bug and mucho thanks for the warning as I was just about to make the move > from 7.0.2 -> 7.2. It doesn't happen to all designs, or even all the pins on a bus. I wrote the code Allan described as #1. This bug appeared in 7.10, and is fixed in 7.11 and the 7.20 betas. The rest of the chip seems to be synthed correctly. The #2/#3 bug is still present in 7.11 and 7.20 beta 2. Cheers Hamish -- Hamish Moffatt VK3SB ###### Message-ID: <3db5354d$0$18869$afc38c87@news.optusnet.com.au> From: hamish@cloud.net.au Subject: Re: Floorplanner RPM. How to use it? Newsgroups: comp.arch.fpga References: <3DB0679F.79D00326@andraka.com> <3DB08AE3.5050909@synplicity.com> <3DB0A12D.8060502@synplicity.com> <3DB0BBF3.4D6C1856@andraka.com> <3DB184BA.1020407@synplicity.com> <3db1a367.1584538@netnews.agilent.com> <3DB2A716.CDA31C91@algor.co.uk> <3db39198.879775@netnews.agilent.com> <3db3c4cd.10160019@netnews.agilent.com> <3DB3EAFD.F2E44BF5@andraka.com> User-Agent: tin/1.5.14-20020917 ("Chop Suey!") (UNIX) (Linux/2.2.18 (i586)) Date: 22 Oct 2002 11:23:57 GMT Lines: 15 NNTP-Posting-Host: 211.28.158.161 X-Trace: 1035285837 18869 211.28.158.161 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!newsfeed.stueberl.de!newsfeed.vmunix.org!news1.optus.net.au!optus!spool01.syd.optusnet.com.au!spool.optusnet.com.au!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22402 Hal Murray wrote: > Is it reasonable to expect a compiler to be able to do-the-right-thing > in all cases like this? Or in most of them? > > Or is this a good example to show that we need some > way to annote/supplement the source code with hints? Not when the result is functionally incorrect. Flip-flops coded with asynchronous resets cannot be converted to SRL16s - SRL16s do not have asynchronous resets. I can live with syn_preserve, syn_replicate etc. Hamish -- Hamish Moffatt VK3SB ###### Message-ID: <3DB5443D.E38B266C@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: Floorplanner RPM. How to use it? References: <3DB0679F.79D00326@andraka.com> <3DB08AE3.5050909@synplicity.com> <3DB0A12D.8060502@synplicity.com> <3DB0BBF3.4D6C1856@andraka.com> <3DB184BA.1020407@synplicity.com> <3db1a367.1584538@netnews.agilent.com> <3DB2A716.CDA31C91@algor.co.uk> <3db39198.879775@netnews.agilent.com> <3db3c4cd.10160019@netnews.agilent.com> <3DB3EAFD.F2E44BF5@andraka.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 48 Date: Tue, 22 Oct 2002 12:28:07 GMT NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: news1.east.cox.net 1035289687 68.15.41.165 (Tue, 22 Oct 2002 08:28:07 EDT) NNTP-Posting-Date: Tue, 22 Oct 2002 08:28:07 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.imp.ch!news.imp.ch!newsfeed.stueberl.de!cox.net!p01!news1.east.cox.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:22333 I do the third one in many cases. I do get occassionally rebuffed for doing so much instantiation, but then it does get the job done. For the others, 'the right thing' is not necessarily the same for everyone and every case. The problem is that what the tools do is not consistent across tool versions, much less across vendors, so you get into the pushing on a rope syndrome quite easily. Hal Murray wrote: > >For the SRL16's, We generally try to put the last clock of delay into a FF > >because of the relatively long clock->Q of the SRL16. I can't have that > >flip-flop getting sucked into the SRL16, even if such modification is controlled > >by the clock period. We generally turn the clock to 0 in synplify to keep it > >from duplicating stuff that is RLOC'd in aggressive designs. That works fine as > >long as the logic between registers is reasonably simple (eg., single level of > >logic), but it also means that I don't want ff's I intend to follow an SRL16 > >getting absorbed into the SRL16. I also don't want the SRL16 inference > >automatically putting a flip-flop at the end if the SRL16 address is dynamic. > >For static SRL16 address, automatic inference of a flip-flop after *EACH* SRL16, > >even when there are several SRL16's in a chain is a nice feature. I believe 7.03 > >does that just for the last SRL16 in a chain. > > Is it reasonable to expect a compiler to be able to do-the-right-thing > in all cases like this? Or in most of them? > > Or is this a good example to show that we need some > way to annote/supplement the source code with hints? > > Or should we just make library packages that instantiate > what we really want whenever we need it? > > -- > The suespammers.org mail server is located in California. So are all my > other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited > commercial e-mail to my suespammers.org address or any of my other addresses. > These are my opinions, not necessarily my employer's. I hate spam. -- --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