From: cjmusial@sprintmail.com (beav) Newsgroups: comp.arch.fpga Subject: Virtex-II Programming Highs and Lows Date: 22 Jan 2002 19:59:47 -0800 Organization: http://groups.google.com/ Lines: 40 Message-ID: <47860154.0201221959.406619f2@posting.google.com> NNTP-Posting-Host: 158.252.149.237 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1011758388 1949 127.0.0.1 (23 Jan 2002 03:59:48 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 23 Jan 2002 03:59:48 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13470 Our team has recently developed a custom image processing board built around several Virtex-II FPGAs. We have also recently developed a variety of algorithms to run within this hardware - and - for the most part the process has been a major success. However, one of the most maddening elements of the process has been the relative ease in which we can "break" a working design by making small changes to "unrelated" code (e.g. VHDL components). Sometimes merely routing signals to our logic analyzer header will cause formerly-functional bitstreams to start putting out rubbish. This all seems to point to proper timing constraints - since even small changes can place logic in different parts of the device. Within our limits of VHDL and timing constraints knowledge (not yet masters), we have (a) overconstrained the synthesis tool (Synplify) and then (b) only constrained the periods on the clocks within the Xilinx tools. In general our design meets almost all of the timing constraints we have set - although the actual video input clock rate is well below our the stated timing performance of the design. Nevertheless, we must be missing something here as we continue to see small changes "break" the design. Often, we can even take this "broken" design, remove the Xilinx constraints, and viola... she starts working again ! I realize this is a vague description, but we are looking for insight on those that may have pushed through such "learning curves". Are there other key things besides the clock periods that should really warrant special attention (perhaps a silly question). Why do we often get better "stability" when leaving constraints out of the design ? If Xilinx tools cannot meet all stated timing objectives, is the resulting bitstream questionable such that we should back off on some numbers and re-run unti all are met ? Sorry for the banter, but any help would be greatly appreciated. Regards, Chris p.s. We are using ES silicon and assume we are not encountering crosstalk or other potential device "glitches" ###### From: strut911@hotmail.com (strut911) Newsgroups: comp.arch.fpga Subject: Re: Virtex-II Programming Highs and Lows Date: 23 Jan 2002 00:47:45 -0800 Organization: http://groups.google.com/ Lines: 20 Message-ID: <4379d3e0.0201230047.162bd6b7@posting.google.com> References: <47860154.0201221959.406619f2@posting.google.com> NNTP-Posting-Host: 24.126.132.195 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1011775665 7906 127.0.0.1 (23 Jan 2002 08:47:45 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 23 Jan 2002 08:47:45 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13473 this is kind of a basic question, but have you guys ran the post-synthesis and post-timing through a testbench? i think in most cases, post-synthesis is good enough to ensure functional verification, and after that, a pass through the static timing analyzer should give good confidence on the post-layout timing. if these all pass, another thing you would probably want to look at is your environment. i just got done spending two days on a problem that did not exist because the environment was noisy. we had such weird data coming out of our system, that we thought for sure that it was a bug. after we moved the system to more of a noise-free environment, the problems disappeared and it was behaving like it should. basically, the fpga should function correctly if you can guarantee the synthesis is correct and the STA passes. one caveat is that the STA is only for synchronous circuitry. if you have a lot of asynchronous signals in your design, and you are seeing some weird stuff, my first suspicion would be to chase after the asynchronous logic portion. in these cases, you should really invest in the xilinx chipscope. that tool is invaluable in terms of isolating a problem to a certain portion of the design. strut911 ###### From: Bob Perlman Newsgroups: comp.arch.fpga Subject: Re: Virtex-II Programming Highs and Lows Message-ID: <8ors4uku4hmnutfo1rm9120f9v7sj831ki@4ax.com> References: <47860154.0201221959.406619f2@posting.google.com> X-Newsreader: Forte Agent 1.8/32.553 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 93 Date: Wed, 23 Jan 2002 08:57:55 GMT NNTP-Posting-Host: 24.221.179.83 X-Complaints-To: abuse@sonic.net X-Trace: typhoon.sonic.net 1011776275 24.221.179.83 (Wed, 23 Jan 2002 00:57:55 PST) NNTP-Posting-Date: Wed, 23 Jan 2002 00:57:55 PST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.newzpig.com!feed.news.sonic.net!typhoon.sonic.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13486 Hi - Getting the place and route tool to meet timing is a little like making balloon animals. We squeeze one end of the balloon and another part of the balloon pops out. Make the horse's head, and all of a sudden you have too much horse's rear end. Similarly, when we place a timing constraint on a set of paths, the place and route tool, which doesn't like to work any harder than it has to, concentrates on those paths at the expense of the others, and all of a sudden the unconstrained paths start coming in at delays you would have sworn were impossible in a modern device. But fair's fair; that's exactly what we told the tool to do. Therefore, when doing FPGA designs, it's important to constrain each and every path in the design. Not just the clock period, or the "critical" paths, but each and every path. And when I talk about constraining a path, I mean constraining it in a way that the router--not just the synthesis tool--knows about. At some point in every design, I find myself spending 2 or 3 days running trce with the -u option. I look at the unconstrained path report, find some unconstrained paths, cover them with a constraint that I add to the .ucf file, then run the router and trce again, until every single unconstrained path is gone. And from that point on, I rerun trce every time I change the design, to make sure that I haven't introduced a path that's not covered by timing delays. This is all tedious, to be sure, but absolutely essential. As for setting timing constraints in Synplify, I haven't found doing so to be all that helpful. I'd rather use the richer set of constraints that Xilinx makes available. Your mileage may vary on this one. But keep in mind that no matter what you tell Synplify, what really counts is the set of constraints that the Xilinx place and route tool sees. One final comment. As you've found out, if a design isn't fully timing-constrained, removing constraints may sometimes temporarily solve a timing problem, because the router may no longer be robbing Peter to pay Paul. This ploy will stop working just before product shipment. Best of luck in fighting your timing battles, Bob Perlman On 22 Jan 2002 19:59:47 -0800, cjmusial@sprintmail.com (beav) wrote: >Our team has recently developed a custom image processing board built >around several Virtex-II FPGAs. We have also recently developed a >variety of algorithms to run within this hardware - and - for the most >part the process has been a major success. However, one of the most >maddening elements of the process has been the relative ease in which >we can "break" a working design by making small changes to "unrelated" >code (e.g. VHDL components). Sometimes merely routing signals to >our logic analyzer header will cause formerly-functional bitstreams to >start putting out rubbish. This all seems to point to proper timing >constraints - since even small changes can place logic in different >parts of the device. > >Within our limits of VHDL and timing constraints knowledge (not yet >masters), we have (a) overconstrained the synthesis tool (Synplify) >and then (b) only constrained the periods on the clocks within the >Xilinx tools. In general our design meets almost all of the timing >constraints we have set - although the actual video input clock rate >is well below our the stated timing performance of the design. >Nevertheless, we must be missing something here as we continue to see >small changes "break" the design. Often, we can even take this >"broken" design, remove the Xilinx constraints, and viola... she >starts working again ! > >I realize this is a vague description, but we are looking for insight >on those that may have pushed through such "learning curves". Are >there other key things besides the clock periods that should really >warrant special attention (perhaps a silly question). Why do we >often get better "stability" when leaving constraints out of the >design ? If Xilinx tools cannot meet all stated timing objectives, >is the resulting bitstream questionable such that we should back off >on some numbers and re-run unti all are met ? > >Sorry for the banter, but any help would be greatly appreciated. >Regards, > > >Chris > >p.s. We are using ES silicon and assume we are not encountering >crosstalk or other potential device "glitches" -- Cambrian Design Works digital design, signal integrity http://www.cambriandesign.com e-mail: respond to bob at the domain above. ###### Message-ID: <3C4EB2AE.D52C668@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: Virtex-II Programming Highs and Lows References: <47860154.0201221959.406619f2@posting.google.com> <8ors4uku4hmnutfo1rm9120f9v7sj831ki@4ax.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 137 Date: Wed, 23 Jan 2002 12:50:04 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@cox.net X-Trace: news2.east.cox.net 1011790204 24.13.238.93 (Wed, 23 Jan 2002 07:50:04 EST) NNTP-Posting-Date: Wed, 23 Jan 2002 07:50:04 EST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.mailgate.org!out.nntp.be!propagator-SanJose!in.nntp.be!yellow.newsread.com!bad-news.newsread.com!netaxs.com!newsread.com!newsfeeds-atl2!newsfeeds-atl1.usenetserver.com!cox.net!news2.east.cox.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:13437 The synplicity constraints are somewhat useful in synthesis, but in my experience, muck up the works if allowed to propagate to the xilinx tools. You also have to careful of them in synplicity because they can cause unexpected logic duplication or worse. Anyway, I have found that a period constraint is often all that is needed, even in fast designs, provided you have coded with keeping the levels of logic minimum. Make sure the synplicity constraints are not sneaking in. If you have write vendor constraints turned on, you get a *.ncf file which xilinx's ngdbuild merges with the *.ucf. If you have an *.ncf, delete it. That said, you are probably a victim of multiple levels of logic. The xilinx placer does pretty well with placing the first level of logic with its flip-flop, and if you floorplan the flip-flops the logic will usually follow. The placer does an exceptionally poor job at placing a second level of logic (ie a lut whose output feeds another lut, not a flip-flop). Even if all the driving signals are local, it will often put the second lut many CLBs away regardless of the timing constraints. Flip-flops are amenable to floorplanning because they tend to keep their names in synthesis. Unfortunately, the luts are not because that is where the famous name changing takes place. Your best bet for consistent results is to keep the logic to a single level. Where you can't, you can a) instantiate the luts (very painful, not very readable), or b) break the design into smaller sub-designs and synthesize each separately so that the scope of synthesis name changes is limited for small design changes. Neither of these is very pleasant, so I prefer to do the design with number of levels in mind. Bob Perlman wrote: > Hi - > > Getting the place and route tool to meet timing is a little like > making balloon animals. We squeeze one end of the balloon and another > part of the balloon pops out. Make the horse's head, and all of a > sudden you have too much horse's rear end. > > Similarly, when we place a timing constraint on a set of paths, the > place and route tool, which doesn't like to work any harder than it > has to, concentrates on those paths at the expense of the others, and > all of a sudden the unconstrained paths start coming in at delays you > would have sworn were impossible in a modern device. But fair's fair; > that's exactly what we told the tool to do. > > Therefore, when doing FPGA designs, it's important to constrain each > and every path in the design. Not just the clock period, or the > "critical" paths, but each and every path. And when I talk about > constraining a path, I mean constraining it in a way that the > router--not just the synthesis tool--knows about. > > At some point in every design, I find myself spending 2 or 3 days > running trce with the -u option. I look at the unconstrained path > report, find some unconstrained paths, cover them with a constraint > that I add to the .ucf file, then run the router and trce again, until > every single unconstrained path is gone. And from that point on, I > rerun trce every time I change the design, to make sure that I haven't > introduced a path that's not covered by timing delays. This is all > tedious, to be sure, but absolutely essential. > > As for setting timing constraints in Synplify, I haven't found doing > so to be all that helpful. I'd rather use the richer set of > constraints that Xilinx makes available. Your mileage may vary on > this one. But keep in mind that no matter what you tell Synplify, > what really counts is the set of constraints that the Xilinx place > and route tool sees. > > One final comment. As you've found out, if a design isn't fully > timing-constrained, removing constraints may sometimes temporarily > solve a timing problem, because the router may no longer be robbing > Peter to pay Paul. This ploy will stop working just before product > shipment. > > Best of luck in fighting your timing battles, > Bob Perlman > > On 22 Jan 2002 19:59:47 -0800, cjmusial@sprintmail.com (beav) wrote: > > >Our team has recently developed a custom image processing board built > >around several Virtex-II FPGAs. We have also recently developed a > >variety of algorithms to run within this hardware - and - for the most > >part the process has been a major success. However, one of the most > >maddening elements of the process has been the relative ease in which > >we can "break" a working design by making small changes to "unrelated" > >code (e.g. VHDL components). Sometimes merely routing signals to > >our logic analyzer header will cause formerly-functional bitstreams to > >start putting out rubbish. This all seems to point to proper timing > >constraints - since even small changes can place logic in different > >parts of the device. > > > >Within our limits of VHDL and timing constraints knowledge (not yet > >masters), we have (a) overconstrained the synthesis tool (Synplify) > >and then (b) only constrained the periods on the clocks within the > >Xilinx tools. In general our design meets almost all of the timing > >constraints we have set - although the actual video input clock rate > >is well below our the stated timing performance of the design. > >Nevertheless, we must be missing something here as we continue to see > >small changes "break" the design. Often, we can even take this > >"broken" design, remove the Xilinx constraints, and viola... she > >starts working again ! > > > >I realize this is a vague description, but we are looking for insight > >on those that may have pushed through such "learning curves". Are > >there other key things besides the clock periods that should really > >warrant special attention (perhaps a silly question). Why do we > >often get better "stability" when leaving constraints out of the > >design ? If Xilinx tools cannot meet all stated timing objectives, > >is the resulting bitstream questionable such that we should back off > >on some numbers and re-run unti all are met ? > > > >Sorry for the banter, but any help would be greatly appreciated. > >Regards, > > > > > >Chris > > > >p.s. We are using ES silicon and assume we are not encountering > >crosstalk or other potential device "glitches" > > -- > Cambrian Design Works > digital design, signal integrity > http://www.cambriandesign.com > e-mail: respond to bob at the domain above. -- --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