From: hristostev@yahoo.com (hristo) Newsgroups: comp.arch.fpga Subject: Block Ram maximum speed Date: 27 Sep 2002 16:27:20 -0700 Organization: http://groups.google.com/ Lines: 7 Message-ID: NNTP-Posting-Host: 143.117.60.34 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1033169240 23564 127.0.0.1 (27 Sep 2002 23:27:20 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 27 Sep 2002 23:27:20 GMT 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!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21414 Hello, what is the maximum possible speed that a BRAM can be clocked with? I am interested on the values for Virtex, Virtex-e, Virtex-2 if someone show me how can i deduce it from the datasheets, i will be really glad thanks ###### Message-ID: <3D953666.6C720BE@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: Block Ram maximum speed References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 34 Date: Sat, 28 Sep 2002 04:50:36 GMT NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: news1.east.cox.net 1033188636 68.15.41.165 (Sat, 28 Sep 2002 00:50:36 EDT) NNTP-Posting-Date: Sat, 28 Sep 2002 00:50:36 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newspeer1-gui.server.ntli.net!ntli.net!cox.net!p01!news1.east.cox.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21401 The block ram speed is limited by the interconnect to it. If you can avoid using the we and ena signals (tie both active and then use the write address count to direct unwanted writes to trash locations) and you pipeline the address and data so that there is no logic between the registers and the BRAM, and you floorplan it so that those registers are on shortest wires you'll get the maximum performance. Numbers depend on the speed grade and the aspect ratio of the BRAM (wide data widths congest the routing forcing one or two to longer routes). Best numbers come from doing a simple test design surrounding the BRAM with registers as indicated and looking at the results. The speed files for the virtexII parts seem to still be in flux. I think the virtexE files finally stabilized after the speed file released in one of the 4.1 sp's. hristo wrote: > Hello, > what is the maximum possible speed that a BRAM can be clocked with? > I am interested on the values for Virtex, Virtex-e, Virtex-2 > > if someone show me how can i deduce it from the datasheets, i will be really glad > > thanks -- --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: <3D95AFE3.D5B78752@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: Block Ram maximum speed References: <3D953666.6C720BE@andraka.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 97 Date: Sat, 28 Sep 2002 13:28:57 GMT NNTP-Posting-Host: 68.15.41.165 X-Complaints-To: abuse@cox.net X-Trace: news1.east.cox.net 1033219737 68.15.41.165 (Sat, 28 Sep 2002 09:28:57 EDT) NNTP-Posting-Date: Sat, 28 Sep 2002 09:28:57 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news-fra1.dfn.de!news-lei1.dfn.de!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.stueberl.de!cox.net!p01!news1.east.cox.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21402 An XC2S -2 probably isn't going to get to 200 MHz with any margin, but you can get closer than you are. There's not a lot you can do about Tbcko or Tdick. Look at the net in between though. 2.2ns is going through a number of segments. You should be able to improve on that with floorplanning the register right next to the BRAM. It may take a look in the FPGA editor to see what the router is doing to you. In 3.3i and earlier versions of the software, the router did a pretty good job of getting a good route if the placement is good. 4.2's router does a much poorer job, even when -ol 5 and -xe 2 switches are set. We still use 3.3sp8 on all but virtexII designs for this reason. You will need to pester your FAE for updated speed files for virtexE for 3.3, the speed files were updated with the release of 4.2sp1, and not officially back annotated into 3.3. It wouldn't be a problem except the propagation delays *increased* in the latest speed file. Falk Brunner wrote: > "Ray Andraka" schrieb im Newsbeitrag > news:3D953666.6C720BE@andraka.com... > > The block ram speed is limited by the interconnect to it. If you can > avoid using the > > we and ena signals (tie both active and then use the write address count > to direct > > unwanted writes to trash locations) and you pipeline the address and data > so that > > there is no logic between the registers and the BRAM, and you floorplan it > so that > > those registers are on shortest wires you'll get the maximum performance. > Numbers > > depend on the speed grade and the aspect ratio of the BRAM (wide data > widths congest > > the routing forcing one or two to longer routes). Best numbers come from > doing a > > simple test design surrounding the BRAM with registers as indicated and > looking at > > the results. The speed files for the virtexII parts seem to still be in > flux. I > > I did this some time ago and got ~7 ns cycle time. See timing analyzer copy > below. It uses a BRAM in 4kx1 mode. > Still 2ns missing for my planned 200 Mhz signal generator :-( > > ---------------------------------------------------------------------------- > ---- > Release 4.2WP3.x - Timing Analyzer E.35 > Copyright (c) 1995-2001 Xilinx, Inc. All rights reserved. > > Design file: generator_hs.ncd > Physical constraint file: generator_hs.pcf > Device,speed: xc2s100,-5 (PRELIMINARY 1.23 2001-12-19) > Report level: verbose report > ---------------------------------------------------------------------------- > ---- > > ============================================================================ > ==== > Timing constraint: NET "clk_BUFGP/IBUFG" PERIOD = 8 nS HIGH 50.000000 % ; > > 286 items analyzed, 0 timing errors detected. > Minimum period is 7.086ns. > ---------------------------------------------------------------------------- > ---- > Slack: 0.914ns (requirement - (data path - negative clock > skew)) > Source: l_singelram6.A > Destination: Mshreg_data_6__ram_reg_6 > Requirement: 8.000ns > Data Path Delay: 7.086ns (Levels of Logic = 2) > Negative Clock Skew: 0.000ns > Source Clock: clk_BUFGP rising at 0.000ns > Destination Clock: clk_BUFGP rising at 8.000ns > > Data Path: l_singelram6.A to Mshreg_data_6__ram_reg_6 > Delay type Delay(ns) Logical Resource(s) > ---------------------------- ------------------- > Tbcko 3.985 l_singelram6.A > net (fanout=1) 2.269 ram_out<6> > Tdick 0.832 Mshreg_data_6__ram_reg_6 > ---------------------------- ------------------------------ > Total 7.086ns (4.817ns logic, 2.269ns route) > (68.0% logic, 32.0% route) > > -- > MfG > Falk -- --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: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: Block Ram maximum speed Date: Sat, 28 Sep 2002 15:53:50 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 13 Message-ID: References: <3D953666.6C720BE@andraka.com> NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1033228430 79366 128.32.112.203 (28 Sep 2002 15:53:50 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Sat, 28 Sep 2002 15:53:50 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed.mathworks.com!news-hog.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:21406 In article , Falk Brunner wrote: >I did this some time ago and got ~7 ns cycle time. See timing analyzer copy >below. It uses a BRAM in 4kx1 mode. >Still 2ns missing for my planned 200 Mhz signal generator :-( Yeup, sounds about right. Thats what I seemed to get when I was doing my AES core, where I had pitch-matched registers before and not very far after the memory. Why not use an XC2S-E? -- Nicholas C. Weaver nweaver@cs.berkeley.edu