From: cjwang_1225@hotmail.com (chris) Newsgroups: comp.arch.fpga Subject: Problems with Virtex Block Ram Propagation Delay Date: 6 Jul 2001 10:47:43 -0700 Organization: http://groups.google.com/ Lines: 13 Message-ID: <24a13eb0.0107060947.2b68ea73@posting.google.com> NNTP-Posting-Host: 216.127.235.130 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 994441663 5750 127.0.0.1 (6 Jul 2001 17:47:43 GMT) X-Complaints-To: groups-support@google.com NNTP-Posting-Date: 6 Jul 2001 17:47:43 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!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:7793 hi. i am doing post-route simulation on a design using the virtex block ram. when i probe at the address and clock inputs, and the data output, i see that there is a 14 ns delay from the clock rising edge to the data appearing on the output data bus. i suspect that there is something wrong with the way i configured the block ram, or some setting i did not perform because the switching characteristic is that the clock -> dout is 4.3 ns for the speed grade i have. the clock is on a clock buffer (bufg) so that the slew rate is not a problem (my original suspicion). i don't think it is routing delay because i am probing directly at the inputs and outputs of the block ram instantiation (RAMB4_S16). does anyone have any suggestions or comments on what could be the problem? thank you in advance. chris wang ###### From: "Kevin Neilson" Newsgroups: comp.arch.fpga References: <24a13eb0.0107060947.2b68ea73@posting.google.com> Subject: Re: Problems with Virtex Block Ram Propagation Delay Lines: 37 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Sat, 07 Jul 2001 06:47:09 GMT NNTP-Posting-Host: 209.245.3.192 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 994488429 209.245.3.192 (Fri, 06 Jul 2001 23:47:09 PDT) NNTP-Posting-Date: Fri, 06 Jul 2001 23:47:09 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Fri, 06 Jul 2001 23:44:53 PDT (newsmaster1.prod.itd.earthlink.net) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!rcn!newsfeed1.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:7564 Chris, I have had similar trouble with the BRAMs. I found that the routing delay in getting the BRAM output anywhere can be as large as the TBCKO (clk->out). I tried registering the BRAM outputs, and found there was a huge delay in just getting the BRAM outputs to the input of a flop. The Xilinx placer also seems to do a poor job of placing BRAMs near the logic they drive or vice versa. This is true even when only a fraction of the part is being used. Maybe there's just an architecture problem. I noticed that Synplify, when making routing delay estimates, way underestimates the actual results, so the design seems to meet timing after synthesis but fails miserably in P&R. When I last had this problem, I just had to come up with a source-code solution. I was using BRAMs as lookup tables, and I used each port of the BRAM as a separate lookup and only used each port every other cycle. Hopefully SpartanII has better BRAM routing. -Kevin "chris" wrote in message news:24a13eb0.0107060947.2b68ea73@posting.google.com... > hi. i am doing post-route simulation on a design using the virtex > block ram. when i probe at the address and clock inputs, and the data > output, i see that there is a 14 ns delay from the clock rising edge > to the data appearing on the output data bus. i suspect that there is > something wrong with the way i configured the block ram, or some > setting i did not perform because the switching characteristic is that > the clock -> dout is 4.3 ns for the speed grade i have. the clock is > on a clock buffer (bufg) so that the slew rate is not a problem (my > original suspicion). i don't think it is routing delay because i am > probing directly at the inputs and outputs of the block ram > instantiation (RAMB4_S16). does anyone have any suggestions or > comments on what could be the problem? thank you in advance. > chris wang > ###### Message-ID: <3B472891.FEF7B6B1@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: Problems with Virtex Block Ram Propagation Delay References: <24a13eb0.0107060947.2b68ea73@posting.google.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 58 Date: Sat, 07 Jul 2001 15:19:19 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 994519159 24.13.238.93 (Sat, 07 Jul 2001 08:19:19 PDT) NNTP-Posting-Date: Sat, 07 Jul 2001 08:19:19 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newshub2.home.com!news.home.com!news1.wwck1.ri.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:7531 There are a couple of things automatic placement is not very good at, and BRAM placement is one of them. For best performance, you'll want to do a bit of floorplanning, and also register the inputs and outputs of the BRAM with just registers (no combinatorial logic in front of the registers). YOu'll also want to floorplan the placement of those registers to get them as close as possible to the BRAMs, especially for the EN and WE if you are using those. The routing around the BRAM is only half the problem (the BRAM tends to congest routing), the long delays into and out of the BRAM are the other half of the problem. A design change to access twice as many bits per access so you can cut the clock cycle to the BRAM in half will probably get you more mileage than tweaking ot get a few more tenths of ns. Kevin Neilson wrote: > Chris, > I have had similar trouble with the BRAMs. I found that the routing delay > in getting the BRAM output anywhere can be as large as the TBCKO (clk->out). > I tried registering the BRAM outputs, and found there was a huge delay in > just getting the BRAM outputs to the input of a flop. The Xilinx placer > also seems to do a poor job of placing BRAMs near the logic they drive or > vice versa. This is true even when only a fraction of the part is being > used. Maybe there's just an architecture problem. I noticed that > Synplify, when making routing delay estimates, way underestimates the actual > results, so the design seems to meet timing after synthesis but fails > miserably in P&R. > > When I last had this problem, I just had to come up with a source-code > solution. I was using BRAMs as lookup tables, and I used each port of the > BRAM as a separate lookup and only used each port every other cycle. > Hopefully SpartanII has better BRAM routing. > > -Kevin > > "chris" wrote in message > news:24a13eb0.0107060947.2b68ea73@posting.google.com... > > hi. i am doing post-route simulation on a design using the virtex > > block ram. when i probe at the address and clock inputs, and the data > > output, i see that there is a 14 ns delay from the clock rising edge > > to the data appearing on the output data bus. i suspect that there is > > something wrong with the way i configured the block ram, or some > > setting i did not perform because the switching characteristic is that > > the clock -> dout is 4.3 ns for the speed grade i have. the clock is > > on a clock buffer (bufg) so that the slew rate is not a problem (my > > original suspicion). i don't think it is routing delay because i am > > probing directly at the inputs and outputs of the block ram > > instantiation (RAMB4_S16). does anyone have any suggestions or > > comments on what could be the problem? thank you in advance. > > chris wang > > -- -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