Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hi, I am trying to evaluate the power consumption of one of my design. But the powerplay power analyser keeps telling me that the metric confidency is low, because much of the toggle rates are vectorless estimated (not computed based on real signal activities). Though, all the toggle rates should come from my VCD file (value change dump file) that I fill with Modelsim simulation. In the powerplay power analyser's report, I can see each signal, and wether its toggle rate has been estimated, or computed using the vcd file. Here is an exemple of what I can read : mat_correl:matcorrel|mul_mgc_mul_pipe_1_z_oreg[0] Combinational cell Simulation file1 mat_correl:matcorrel|mul_mgc_mul_pipe_1_z_oreg[0]~feeder Combinational cell Vectorless estimation I can trace back the first signal in my design, even in modelsim with a find signals *pipe_1_z_oreg* But I don't find any signal with "feeder" in the name. If someone could explain me why Quartus adds "ghost" signals with ~feeder at the end, it would help. I have the same problem with RTL or gate level simulation. Quartus 6.0 or 6.1. many thanks in advance, Alexandre.Article: 116001
Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote: > > * Pin-compatible with select members of the Spartan-3A FPGA family > + Architecturally identical to Spartan-3A FPGA family This last point would seem important. So if one places external flash alongside a 3A, (That flash being larger, or smaller, (or faster?) than the in-package Flash of 3AN) you get all the same Flash-access features ? -jgArticle: 116002
On Feb 27, 10:36 am, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote: > > > > > * Pin-compatible with select members of the Spartan-3A FPGA family > > + Architecturally identical to Spartan-3A FPGA family > > This last point would seem important. So if one places external flash > alongside a 3A, (That flash being larger, or smaller, (or faster?) than > the in-package Flash of 3AN) you get all the same Flash-access features ? > > -jg Correct. You have many of the same Flash size advantages by connecting an external Flash to a Spartan-3A device. Obviously, however, it is no longer a single package. The Spartan-3AN In-System Flash memory requires no user-I/O pins. Instead, all access is through an internal design primitive called SPI_ACCESS. I should also mention that Spartan-3AN FPGAs still support _all_ the other Spartan-3A configuration modes (Master Serial, Master Parallel, Slave Serial, etc.). Spartan-3AN FPGAs exclusively offer the Internal Master SPI mode. -- Steve KnappArticle: 116003
"Josep Duran" <djj08230@gmail.com> wrote: >On Feb 26, 11:32 am, Uwe Bonnes <b...@hertz.ikp.physik.tu- >darmstadt.de> wrote: >> While both Device/package combinations are listed in the datasheets, I have >> not seen any of these devices "out in the wild" (means available with >> Digikey(*)/Nuhorizons/Avnet). > > >Avnet lists some parts as available : > >XC3S400-4PQ208I >XC3S400-4PQG208C >XC3S400-4PQG208I >XC3S400-5PQ208C >XC3S400-5PQG208C > >Real availability is another issue, which I happen to be interested >too. I got a quote for a small quantity XC3S400-5PQ208C from Avnet a while ago and they said the devices could be delivered from stock... -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 116004
Tim wrote: > Ray Andraka wrote: > >> It would be better to set the BRAMs up as 16Kx1, using as many as you >> need for bits and then a simple 2:1 mux to select between two banks >> for the 32K size. This eliminates a lot of the external logic by >> using more of the internal decode. As a result you get considerably >> better timing and power dissipation. Also, it turns out it is much >> easier to route because each BRAM has only one read data and one write >> data rather than the full width of the BRAM. > > > Just a note for the archive: I agree with Ray, but if power consumption > is a consideration, you need to experiment with both implementations. > Some architectures have power burn strongly affected by the number of > enabled BRAMs. Either way you have the same number of BRAMs unless your data bus is the right width to take advantage of the parity bits in the wider configuration to reduce the BRAM count. I don't recall what the OP's width was, but I was thinking it was 16 bits, in which case the parity bits aren't used. In any event, the extra logic needed to mux 32 banks of 16/19 bit wide BRAMs rather than the 2:1 mux needed to select from pairs of 16Kx1 banks is going to consume far more power than an additional BRAM. I didn't mention it in my original post, but the logic resources used are less for the 16Kx1 implementation as well. Generally speaking, you want to use the deepest aspect ratio that fits with your design. The exceptions come in for special cases where the number of BRAM available is limited and using the parity bits will reduce the BRAM count.Article: 116005
"Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com> wrote: >On Feb 26, 10:12 am, "Antti" <Antti.Luk...@xilant.com> wrote: >> finally announced! >> >> so now can talk about them - well still not documents on Xilinx >> website, but hopefully they will be available shortly >> >> Antti > >I am pleased to announce that the Spartan-3AN FPGA family is now >officially out in the open. Full technical literature is now >available on the Xilinx web site. > >Spartan-3AN Non-Volatile FPGA Family >http://www.xilinx.com/spartan3an > >Spartan-3AN Technical Literature Page >http://www.xilinx.com/xlnx/xweb/xil_publications_display.jsp?category=Publications/FPGA+Device+Families/Spartan-3AN > Hmm, no PQ208 package. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 116006
Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote: > I am pleased to announce that the Spartan-3AN FPGA family is now > officially out in the open. Full technical literature is now > available on the Xilinx web site. Can you summarize the availability picture for the various parts for prototype quantities and for production quantities?Article: 116007
Ray Andraka wrote: > In any event, the extra logic needed to mux 32 banks of 16/19 bit wide > BRAMs rather than the 2:1 mux needed to select from pairs of 16Kx1 banks > is going to consume far more power than an additional BRAM. What you say may be true in almost all cases - I haven't done the comparison across the many and various FPGAs. But it certainly isn't true for at least one Xilinx family - if power consumption is an issue it's worth making the checks and knowing for sure.Article: 116008
Tim, >From the press release: "Pricing and Availability Customers can immediately begin designing systems with Spartan-3AN FPGAs using the ISE™ 9.1i design tool suite and Spartan-3 Generation library of application-specific IP. Engineering samples are shipping now for the XC3S200AN, XC3S700AN and XC3S1400AN devices with all five devices in production by Q3 2007. At customer production timeframes at the end of 2007, Spartan-3AN devices will offer designers over 4,000 logic cells and 195 I/O for USD $4.90*, resulting in the world’s first integrated FPGA offering 4Mbits of flash for under $5.00." *250k resale volume, 3S200AN-4FT256C We decided to try something different this time: have stock of the items noted on the shelf at the time of release. 200, 700, 1400 available now. Production orders for all five family members accepted by end of 2007. AustinArticle: 116009
Austin Lesea <austin@xilinx.com> wrote: > Tim, > From the press release: > "Pricing and Availability > Customers can immediately begin designing systems with Spartan-3AN FPGAs > using the ISE??? 9.1i design tool suite and Spartan-3 Generation library > of application-specific IP. Engineering samples are shipping now for the > XC3S200AN, XC3S700AN and XC3S1400AN devices with all five devices in > production by Q3 2007. At customer production timeframes at the end of > 2007, Spartan-3AN devices will offer designers over 4,000 logic cells > and 195 I/O for USD $4.90*, resulting in the world???s first integrated > FPGA offering 4Mbits of flash for under $5.00." > *250k resale volume, 3S200AN-4FT256C > We decided to try something different this time: have stock of the items > noted on the shelf at the time of release. > 200, 700, 1400 available now. Production orders for all five family > members accepted by end of 2007. Did you try in the "Xilinx" web-shop? Every item is "No stock. Call for info" -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 116010
Tim wrote: > Ray Andraka wrote: > >> In any event, the extra logic needed to mux 32 banks of 16/19 bit wide >> BRAMs rather than the 2:1 mux needed to select from pairs of 16Kx1 >> banks is going to consume far more power than an additional BRAM. > > > What you say may be true in almost all cases - I haven't done the > comparison across the many and various FPGAs. But it certainly isn't > true for at least one Xilinx family - if power consumption is an issue > it's worth making the checks and knowing for sure. Tim, I am failing to see it. If you are building a 16x32K memory, for example, you could do it with 32 16Kx1 plus 16 2:1 muxes, or you could do it with 32 1Kx18 BRAMs plus 16 16:1 muxes, which occupies about 3x the number of LUTs. Same number of BRAMs, more logic. If have a width where you use the parity bits, then yes there is a difference in the BRAM count, for example an 18x32K you use 36 16Kx1 or 32 1kx18. In that case, then yes you use 4 more BRAMs, to save a relatively small number of LUTs, and the power consumption is probably less. In the general case though, the answer depends on the candidate BRAM organizations, and this is only true because the extra memory density is only available in the x9, x18, and x36 configurations.Article: 116011
Austin Lesea wrote: > From the press release: <snip> So I should work on the basis that Xilinx press release statements of price and availability are rock-solid! Would it be reasonable to track the Spartan-3A in the Web Shop or in Distribution and work on the basis that equivalent parts in the 3AN range will be coming along six months later?Article: 116012
"Ray Andraka" <ray@andraka.com> wrote in message news:aB3Fh.219671$IL1.61458@newsfe13.lga... > > Tim, I am failing to see it. > If you are building a 16x32K memory, for example, you could do it with 32 > 16Kx1 plus 16 2:1 muxes, or you could do it with 32 1Kx18 BRAMs plus 16 > 16:1 muxes, which occupies about 3x the number of LUTs. Same number of > BRAMs, more logic. > > If have a width where you use the parity bits, then yes there is a > difference in the BRAM count, for example an 18x32K you use 36 16Kx1 or 32 > 1kx18. In that case, then yes you use 4 more BRAMs, to save a relatively > small number of LUTs, and the power consumption is probably less. > > In the general case though, the answer depends on the candidate BRAM > organizations, and this is only true because the extra memory density is > only available in the x9, x18, and x36 configurations. The point I saw in his earlier post: if you have 32 16kx1 memories, you're enabling at least 16 memories. If you use 32 1kx16 memories, only one needs to be enabled. If the power for 15 enabled RAM access cycles (versus disabled cycles) is significantly greater than the power for the multiplexer logic and increased routing burden, the power question isn't a gimme. If all 32 memories are always enabled in both schemes, the point is moot; the 16kx1s will win out. If only the decoded memory is enabled, the difference might be large. Or it might not. - John_HArticle: 116013
"Tim" <tim@nooospam.roockyloogic.com> wrote in message news:es2gma$lut$1$830fa7a5@news.demon.co.uk... > Austin Lesea wrote: > >> From the press release: > > <snip> > > So I should work on the basis that Xilinx press release statements of > price and availability are rock-solid! > > Would it be reasonable to track the Spartan-3A in the Web Shop or in > Distribution and work on the basis that equivalent parts in the 3AN range > will be coming along six months later? Unlike buying a toaster, the price for an FPGA is never rock-solid, even for one moment in time for the same quantity. Prices are often negotiable if the difference between a socket win or loss can have an impact on business, present or future. Unfortunately you can't enter your parameters into a spreadsheet and come out with a single price valid for anyone with those same circumstances. If you have a relationship with your sales rep, explore the options available to you. If Xilinx wants your business more than giving it to one of its competitors, your sales rep might negotiate a price your distributor will honor. Much of the electronics component pricing is affected to this degree. Reps can help get a negotiated price that will keep the business without harming later business opportunities. I'd love to have complete, fair, unbiased pricing that's applicable across companies and countries. The reality is that support needs for different size (and experience) customers vary and the bottom line impact can be significant or hard to notice. The price will fit your need; if it doesn't, another vendor will fit your need. If you have a need that must be filled, it will be filled. Just not necessarily at the price you want or the vendor you prefer. At least there's a stake in the sand.Article: 116014
Tim, Uwe, I am told that parts were shipped to distributors, so they would be on hand on the day of the introduction. Why else would we be so fussy about the strict adherence to the release of information? Parts, software, documentation, cores -- it all has to come together. One item missing is unacceptable. The X-Store is another matter, and as you well know, Peter and I both continue to spend time to try to improve that situation. The real good news is that the 3AN hits the streets today with ES parts on the shelves of distributors. The lead times are stated at 2 to 4 weeks in all the paperwork I have seen (probably just to make sure we do not disappoint anyone, anywhere). Remember, we are changing how we introduce new products, and hope to regain the trust of our customers. AustinArticle: 116015
Ray Andraka wrote: > Tim, I am failing to see it. > If you are building a 16x32K memory, for example, you could do it with > 32 16Kx1 plus 16 2:1 muxes, or you could do it with 32 1Kx18 BRAMs plus > 16 16:1 muxes, which occupies about 3x the number of LUTs. Same number > of BRAMs, more logic. Yes. But the power consumption can also vary depending on how many BRAMs are active. It depends on the BRAM implementation and I haven't looked at the V4 case. By effectively freezing most of the BRAMs at any moment, the power hit goes down. It's the same with external SRAM and DRAM, where the power consumption goes up and down with the number of banks active, the number of RAMs active, and the read/write/refresh state. For the common case, where the finer details of power saving aren't a concern, the point you made is the most relevant - use as much as possible of the BRAM's internal decode logic. It's probably faster, almost certainly it uses less power, and it's free.Article: 116016
Dear all,
I am using Syplify8.5 and Xilinx Webpack 9.1 to implement a CPLD
XC95144XL, Verilog simulation showed everything fine, but P&R showed a
warning message as follows
Cannot apply TIMESPEC TS_WR =PERIOD:WR_CPLD:50.000nS:HIGH:25.000nS
WR is simply an input clock used to latch another signal, such as
always @(posedge WR)
begin
Ext_Data_Latched <= Ext_Data_In;
end
Does anybody know how to resolve this or I just simply ignore this
warning message? Thanks
Article: 116017John_H wrote: > Unlike buying a toaster, the price for an FPGA is never rock-solid, even for > one moment in time for the same quantity. Prices are often negotiable if > the difference between a socket win or loss can have an impact on business, > present or future. Unfortunately you can't enter your parameters into a > spreadsheet and come out with a single price valid for anyone with those > same circumstances. I understand. Business schools study whether this sort of detailed pricing is a necessity or a make-work program for the sales and marketing department. It must surely absorb spectacular levels of scarce management time. For what we need as engineers, a set of pricing curves (with a few spot prices) would be just as good as real prices. It would be up to the folk in buying to force the pricing curve as low as possible. For instance, many many years ago Peter A pointed out that, for the products out there at the time, speed grades cost about 10% each, and bigger packages (there weren't too many to choose between) cost around 10% each. Right now, I get the sense that for a given part speed grades cost a little more than 10% and the price includes a package element by being more or less linear with the usable pin count. (This is medium volume - high volume rules are different) This makes an engineer's life easy (!) because costs are roughly linear with benefits. But comparing between parts and between ranges involves poring over the distributor's price charts. It would be much easier if the relative curves were graphed. For instance, Spartan-3, 3E, 3A approx the same price per LUT/per pin, 3AN is x% higher, faster speeds 15% higher. Or something similar.Article: 116018
BTW, I tried using XC95144XV and XC95288, both do not show this warning. So can I just assume this warning can be ignored for XC95144XL? On 2=A4=EB28=A4=E9, =A4W=A4=C88=AE=C954=A4=C0, heliboy2...@yahoo.com.tw wro= te: > Dear all, > > I am using Syplify8.5 and Xilinx Webpack 9.1 to implement a CPLD > XC95144XL, Verilog simulation showed everything fine, but P&R showed a > warning message as follows > > Cannot apply TIMESPEC TS_WR =3DPERIOD:WR_CPLD:50.000nS:HIGH:25.000nS > > WR is simply an input clock used to latch another signal, such as > > always @(posedge WR) > begin > Ext_Data_Latched <=3D Ext_Data_In; > end > > Does anybody know how to resolve this or I just simply ignore this > warning message? ThanksArticle: 116019
Hi Eilert, i have just compiled it successfully, Thank you very much for your supporting.Article: 116020
Luzerne wrote: > On 26 fév, 08:47, Steve Battazzo <thesteveman_i...@yahoo.co.jp> wrote: >> I found some page online in french that actually came out somewhat >> readable when translated to English, describing how to install version >> 8.1i in Ubuntu 6.06 (which is what I'm using). > > I wrote a french article on this topic, so if the mentionned page is > this one : > "Installation Xilinx Webpack 8.1i sur linux (ubuntu 6.06 "dapper > drake")" > http://harded.free.fr/site/?p=55 > > Then I am probably the one to blame for the choice of french language > instead of common english :) I don't know how the "automatic" > translated version is, but if you have specific questions I can write > some "non automatic" human explanations :) > > >> I tried that, but only >> got checksum errors when I tried to run the .sh file. >> Any ideas? > > This is maybe now solved, and you have probably take care of that... > but just in case... > Did you check you really have enough free disk space for the > downloaded file ? I got the same kind of error because my disk > partition get full before the end of the download. > > Hope this help. > > Luzerne GANHIR > Thanks, I did manage to get it working though I still don't know why the solution I chose ended up working.... Can't be a disk space issue, I have an 80 gig hard drive and only about 10 gigs of space is occupied at the moment.Article: 116021
jonas@mit.edu wrote: >> Directly from the Xilinx website, I've been getting issues with these, >> whether it's the single file download or the web install. 9.2i installer >> gave me a bus error and with the older versions the script files gave me >> some checksum errors as I said before (wget or otherwise). >> I found some old mirror sitehttp://www.tx-g.net.hu/files/xilinxthat >> had the files for 8.2i archived. I tried the WebInstall version from >> there (as it's a smaller file) and it actually opened, but the install >> didn't succeed. >> This led me to suspect that the single file install from this mirror >> would probably work ok for me. It is a slow server and took over 3 hours >> to downoad (against 20 minutes straight from Xilinx) but the install >> worked! >> >> I do have an AMD64 Athlon processor, so I may be interested in hearing >> your script file edit. >> Is it the settings.sh, Display:= 0 thing that I've been seeing around, >> or something else? >> > > First, and I know this sounds dumb, but I'd suggest booting into > memtest86 (ubuntu ships it by default as one of your boot options) and > checking your ram. Every time I've had strange download problems it's > ended up being a ram problem -- and this has happened three times over > the past few years. > > I found that I had to edit the top of settings.sh to identify my > platform as an x86 (and not x86-64) linux. > > PLATFORM=lin > > > > Why xilinx doesn't also release 64-bit webpack, I'm not sure :) But > their linux support has been so nice that I'm not complaining. Maybe > someday they'll actually package rpms or debs for us! > > I'm curious, what do you use for HDL sim under linux? > > ...Eric > What do I use for HDL sim? Well, I don't know yet. I'm a beginner, just trying to get some software set up so I can start learning. For now I will just use the ISE webpack for everything until I get to a point where I see a need for anything else. There are both windows and linux machines in the lab that I can use, so if I were to do this just in the lab I could take my pick.. but I'd like to play around with it at home for a bit as well and I just switched to linux, trying to put my windows machine to rest. And in the lab, for that matter, I'd like to stay off the windows machine because that particular one sucks... I've been using it for microcontroller and serial debugging, but I have almost reached the point where I can move those things over to linux too :) As for the ram test.. I'm running that right now and everything seems to be checking out. This is a new computer, I just put it together less than a week ago, so I'm still working out the kinks but there don't seem to be any big hardware issues. Thanks again for your help! SteveArticle: 116022
Hello, Does anyone know if there is a Spartan based uBlaze development board that has SRAM on it? Best regards, RobArticle: 116023
MotM wrote: > Is there a way to access the platform cable USB from a user program > (i.e., from outside the Xilinx toolchain) ? What I'd like to do is > access a BSCAN module inside my design from a custom win32 > application. Andreas Ehliar wrote: > Take a look at the following URLs: > http://www.xilinx.com/publications/xcellonline/xcell_53/xc_jtag53.htm > and http://www.s3group.com/system_ic/gnat/ Those articles show how to acess the JTAG interface from logic inside the FPGA. What MotM wants is to access the JTAG chain from the PC. Unfortunately Xilinx does not provide any API to do this, and believes that the interface to their PC4 and Platform USB cables is some kind of super-valuable trade secret, so the answer is that you can't do it with the Xilinx cable. You have to use a third party JTAG interface, and swap JTAG cables back and forth. :-( There *must* be some kind of API that Xilinx uses in their own software to do this. C'mon, guys, open it up for customer use! EricArticle: 116024
On Feb 27, 11:38 pm, Eric Smith <e...@brouhaha.com> wrote: > Unfortunately Xilinx does not provide any API to do this, and believes > that the interface to their PC4 and Platform USB cables is some kind > of super-valuable trade secret, so the answer is that you can't do > it with the Xilinx cable. You have to use a third party JTAG interface, > and swap JTAG cables back and forth. :-( I believe that one option is to use the Xilinx cable, but download your own firmware to it rather than the firmware the Xilinx tools download. Since the firmware defines the interface, you can then use it anyway you like... It is a Cypress fx2, isn't it? Or is is that only true of the Digilent cables? It is one of the FTD chips?
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z