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
Jeff Cunningham wrote: > Matthew Hicks wrote: > > While I like Xilinx and think their docs, if you read enough of them you > > will find three things > > 1. Some things that aren't documented enough > > 2. Some things that aren't documented at all > > 3. Some things that aren't documented correctly > > 4. Some things are documented somewhere, but good luck finding it. Yes, I went through a discussion in this group a while back about information that seemed to be missing from the Spartan 3 data sheet, but in fact was just well hidden. It was scattered over a large portion of the document rather than being in one place. After a lot of discussion, one of the Xilinx regulars here had the data sheet amended to help with the problem. Of course it really needed a thorough review and much more extensive editing, but that was a start. I also got Atmel to amend the AT91SAM7S data sheet to include enough info on the crystal that you can almost spec one to use. Documentation is often the poor stepchild of a development process. I know where I work there are tons of instructions and procedures and processes on how to prepare documentation. Then the documents that result are hard to understand, incomplete and sometimes even wrong. It can take forever for them to be updated because there is no incentive to return to them once they are completed. Personally I take pride in the documents I prepare. I never want anyone to read one of my documents and think it was written by a moron, even if it was! ;^)Article: 110376
Avion wrote: > thanks for the help. let me try n i hope it will work. but isn't it > much easier in schematics to connect signals? is there anyway in > schematics as well? one way may be to create a schematic of the wrapper > file u just suggested and then use it. am i right? After using half a dozen different schematic packages over a period of about 20 years, I finally gave up on schematics about 6 years ago. I like schematics, but they simply are not portable, and you end up having to keep around an old computer and operating system and schematic software to support old projects. You really should abandon them; pick and use an HDL of some. I personally have never used the Xilinx schematic software, so I can give no help on that.Article: 110377
subint wrote: > Hi, > i would like to know which is the best if i want a FPGA ( with > 150k virtex4 equavalent LUTs) and low cost. > thanks in advance > subin Does your design need to be 150k tightly coupled LUTs running at 400 MHz? Do you need massive memory? Any memory? Consider partitioning your design into several smaller FPGAs, divided up per your parallelism or by functional blocks. You can get 35k LUT FPGAs for a very reasonable price: Lattice ECP2-35, Xilinx XC3S1600E, Altera EP2C35. I choose these parts because I think they're more toward the "sweet spot" of the price curve. You can get larger devices in these families from Altera and Lattice or bump up the size in the Xilinx Spartan3 family (as opposed to the 3E just mentioned). If you need large amounts of on-chip memory or multi gigabit communications, the new Lattice ECP2M series warrants serious consideration. These devices are all designed for cost over speed. depending on the complexity of your system, 66 MHz to 200 MHz system designs are achievable, not 400 MHz type speeds. Typically, higher design speed is achieved through careful coding representative of well-seasoned FPGA designers. ASIC designers often don't have the speed pressure that FPGA folks have but you can find strong expertise in both camps. So - how much are you willing to work in order to save money? Can you achieve what you want by improving your design approach (particularly if you have a very low system speed) or by creative partitioning into multiple FPGAs? Good luck in your endeavors. - John_HArticle: 110378
rickman wrote: > Funny, I think I understood what you were asking by your second post > here. I don't know why Xilinx does not understand. They seem to want > to answer the wrong question and then when you tell them they answered > the wrong question they seem to think *you* are the one that > misunderstands. > > I have seen this more than once and with more than one person at > Xilinx. I don't know if it is a corporate culture thing to not be > willing to reexamine their thinking or if it is just the individual > people, but I have seen this on numerous occasions. > > Perhaps if you asked in an extremely detailed way that left no room for > misunderstanding? Specify the pin number of the signal you are using > to keep them from thinking you are using SSTL on the JTAG pins. Ask > specifically what the threshold level will be on that pin during > boundary scan after you have loaded the configuration. *Do not mention > any other information that you may think will be helpful if it is not > required!!!* Any stray info can result in misinterpretation. I have > seen many times that the mention of a piece of information that should > help to clarify your thinking actually results in alarm bells going off > on the other side and the discussion goes way off course. > > Good luck! rickman - I give you kudos for understanding what colin is trying to achieve. I've watched this thread and I'm still confused. My engineering career started in manufacturing where I had extreme interest in boundary scan. Yet, I'm stymied. The issue of IO standard is external to any registers in an internal scan chain. I couldn't figure out if there was a need to interface to the jtag chain in SSTL logic or if there was a perceived internal need for the jtag chain to be driven by SSTL to scan SSTL I/O cells. If the scan was 1) desired before configuration, 2) designed to drive, receive, or tristate signals based on the scan chain, or 3) use the existing configured design, this casual observer still has no clue. It seems there are assumptions that aren't discussed in setting up the problem that needs to be solved. Often, assumptions can be determined from the context. If these underlying assumptions are guessed incorrectly, the wrong question is answered. So - any idea what's really needed?Article: 110379
"subint" <subin.82@gmail.com> wrote in message news:1160821923.691563.325170@m7g2000cwm.googlegroups.com... > Hi, > Yes i mean 150k LUTs.. i checked all these websites but only > xilinx is projecting the LUT counts. Altera projecting there features > with ALM and they saying it's is almost equvalent to 2 slice > etc.Lattice semiconductors clamming they are better and FAST. > I am totally confused. That's because all FPGA/CPLD suppliers use a different 'unit of measure' when classifying their devices. There is currently no good unit of measure that can be used to compare across different manufacturers...but read on. > By saying low cost i just mean the comparision(if there are more > than one source with these features). OK. > when i synthesized my project it's taking almost 80% of the > virtex4(Lx200) ( it have 180kLUTs) . i think lx200 cost about $7000. i > am looking for a alterative if available.... There are alternatives. If you have a design and it has been synthesized to target Xilinx then 'all you need to do' is take that same design and synthesize it to an Altera device family, Lattice device family, Actel, etc. When you do this you'll get a report from each synthesis effort that tells you how many logic resources of are used. The units of measure will be in whatever units the supplier calls them thus avoiding the generic (and sometimes misleading) conversion from brand X units to brand A, brand L, brand whatever. Once you have the tools from the various suppliers (or have something like Synplify which can target them all) the process is straight forward. The catch is in the phrase 'all you need to do....'. If you have taken advantage of any Xilinx specific primitives in your design you'll have to come up with a vendor neutral approach to eliminate the Xilinx specific parts so that you can even run the synthesis to target the other devices. If you find that you have a 'lot' of Xilinx specific primitives and the effort to make the design vendor neutral is too high just to make a determination of which device to target than what you can do is come up with a vendor neutral design that in some fashion mimics roughly what you want to accomplish but maybe doesn't have all of the logic implemented. Then run through the various tools to see how many logic resources get used. Even though what you've synthesized is not your entire design it should be enough for you to develop the conversion factors so that you can compare resource usage among the various suppliers. Once you've completed this effort you should be able to say precisely which Actel, Altera, Lattice, Xilinx, etc. part your design will fit into and compare prices directly. The other thing to keep in mind when you strip out vendor specific stuff though are just what things you're stripping out and if they are 'special' to that part. Things like multipliers and PLLs come immediately to mind here. You'll have to mentally keep track of these 'special' things if the other supplier parts don't have them...and what impact that will mean to your design if you need them. For example, multipliers can be synthesized with logic cells (but are usually going to be slower than a hard multiplier) but PLLs can not be synthesized at all so you're design flat out won't work if you need them. KJArticle: 110380
John_H wrote: > rickman wrote: > > Funny, I think I understood what you were asking by your second post > > here. I don't know why Xilinx does not understand. They seem to want > > to answer the wrong question and then when you tell them they answered > > the wrong question they seem to think *you* are the one that > > misunderstands. > > > > I have seen this more than once and with more than one person at > > Xilinx. I don't know if it is a corporate culture thing to not be > > willing to reexamine their thinking or if it is just the individual > > people, but I have seen this on numerous occasions. > > > > Perhaps if you asked in an extremely detailed way that left no room for > > misunderstanding? Specify the pin number of the signal you are using > > to keep them from thinking you are using SSTL on the JTAG pins. Ask > > specifically what the threshold level will be on that pin during > > boundary scan after you have loaded the configuration. *Do not mention > > any other information that you may think will be helpful if it is not > > required!!!* Any stray info can result in misinterpretation. I have > > seen many times that the mention of a piece of information that should > > help to clarify your thinking actually results in alarm bells going off > > on the other side and the discussion goes way off course. > > > > Good luck! > > > rickman - I give you kudos for understanding what colin is trying to > achieve. I've watched this thread and I'm still confused. My > engineering career started in manufacturing where I had extreme interest > in boundary scan. Yet, I'm stymied. > > The issue of IO standard is external to any registers in an internal > scan chain. I couldn't figure out if there was a need to interface to > the jtag chain in SSTL logic or if there was a perceived internal need > for the jtag chain to be driven by SSTL to scan SSTL I/O cells. > > If the scan was 1) desired before configuration, 2) designed to drive, > receive, or tristate signals based on the scan chain, or 3) use the > existing configured design, this casual observer still has no clue. > > It seems there are assumptions that aren't discussed in setting up the > problem that needs to be solved. Often, assumptions can be determined > from the context. If these underlying assumptions are guessed > incorrectly, the wrong question is answered. > > So - any idea what's really needed? I will explain what I think is going on and Colin can correct me if I am wrong. They are using a Coolrunner II to interface to an SSTL device. The CPLD is first configured, then they want to run boundary scan to test the board. In order to assure their customers that boundary scan will properly verify the connection to the SSTL device, they want to verify that during boundary scan the CPLD will be using SSTL voltage levels on the pin that connects to the SSTL device. This is not one of the JTAG pins, it is just a general IO pin. So the question is, will this pin use SSTL signaling during boundary scan if it is first setup as an SSTL IO during configuration? Is that clear? I fully expect the answer is that the pin will be using SSTL voltage levels during boundary scan. But I can see where the OP would want to ask to make sure. You can never be too sure how chips work internally regardless of what seems obvious.Article: 110381
Reconfiguration time is measured in ms (especially for a small part). And, as Austin told you, reconfiguration does not take much current, probably less than normal operation. So it all depends on the frequency of reconfiguration (once a minute, a second, or a ms?) and on the savings in static and dynamic power (and money) you get from using a smaller part. No need to generalize, but it should be easy to assess your individual situation. Peter Alfke, from home. On Oct 13, 12:46 pm, pbdel...@spamnuke.ludd.luthdelete.se.invalid wrote: > >I've been reluctant recently on envisaging a Virtex-4 device as being > >operational in a battery-powered situation. The inrush configuration > >current, high static power consumption, and the non-uniform power > >exhibited subject to temperature rise are amongst few to name about the > >shortcomings of SRAM FPGAs in general. Having said that, the > >unprecedented versatile reconfigurable processing power is yet the > >decisive factor in prototyping intensive DSP operations. My question > >is: has any body come across a scenario in which a large FPGA was > >battery-powered. I'm in the phase of deciding on solutions to employ > >for my active research so it's quite critical. I don't want to start my > >research with a major gap in my rationale. Can any veteran in here > >comment on the topic please. Is it really ridiculous to think about > >powering a large SRAM FPGA from a battery? Would really appreciate all > >comments. What's the cheapest price ever a smallest Virtex-4 device was > >reported?You said Xilinx fpga, but maybe actel's eeprom (?) based fpgas will do better > for battery applications?Article: 110382
I am currently in my 3rd year of Electrical Engineering undergrad at Ryerson University in Toronto, Ontario, Canada. The internship (if acquired) is slated to start right after this academic year. This effectively delays my graduation by 1 yr, but I think that is a really small price to pay for the experience. Here is a rudimentary list of my skills, a more thorough one will be submitted w/ my resume: Programming Languages: C, Java, Visual Basic, Assembly, Win32 programming, Python Compilers/Environment: GNU tools, Microsoft Visual Studio Microprocessors/Microcontrollers: M680x0, Z80, x86, 8051, PIC, MSP430, ARM7, HC11, Renesas SuperH series proemulator.sf.net I ported my Z80 emulator to this app some time ago. My M68000 emulator is working and is tested to be quite accurate, but the author no longer maintains it or updates it so I decided against porting it (even though I can still get into the CVS). Programmable Logic: Xilinx Spartan3 series FPGA w/ Xilinx ISE WebPack I designed a simple VGA frambuffer 320x240x2-bit and a simplistic 16-bit CPU in VHDL. Electronics: Basic analog electronics (FET's, OpAmps, BJT's, etc.) Here all I did was some school projects. Simple stuff: VCO's, FET amps, etc. Operating Systems: Linux, MS-DOS, Windows (effective w/ all). Been doing installs on all OS's for quite some time now. Used MS-DOS while I was growing up (had it first running on a 16Mhz 386SX). Most the stuff I have learned was from buying products containing the previously mentioned items and playing around with them and their associated tools and reading my dads old college books (he studied electronics engineering technology at NAIT. They did extensive course work in digital electronics). I really do not have any related engineering experience. I did work for GO Transit this past summer, a major transportation company here in Ontario, as general help. I was called on one day to look over some computer scans of microfilm schematics of the trains (and electrical systems) to make sure they were up to par. I would like to shadow some teams in the engineering sector to get a feel of what you guys do in the industry. I would like to see how you guys solve problems, tackle issues or shortcomings you come up in development and the like. I'd also like to learn from the people working in this industry in general since they have a wealth of knowledge and experience. Sometthing I think can be invaluable to me in my career. They have some listings at my school, but they are not exactly what I am interested in. Thanks for listening to my story! Any companys you know of in Toronto? I know Altera has some offices here. Might try and get a hold of them later on. -Isaac (This is a reposting as suggested by a responder in the previous posting)Article: 110383
Hi Thang, sure you can. Just replace .zip with .exe =). http://www.xilinx.com/direct/swhelp/ise8/81i_sp1/8_1_01i_win.exe Sorry for this typo. All other archs using *.zip, only windows use *.exe =(. Regards Jens Thang Nguyen schrieb: > Hi Jens, > > I use Window. It looks like there is only the Add directory, which includes ISEExamples, and Replace directory, which includes docs. I can not update to the sp1 with these two directories. :( > > Thang NguyenArticle: 110384
Rick, Configuration does not require a "significant amount of energy." Not sure where you got that. AustinArticle: 110385
hi well thanks for all the answers so far. i 'm still trying to get some more speed out of edk. well as said before i'm not doing anything fancy. just straight forward stuff and i was wondering what good the ethernet core is if i can't get it to synthesize with more than 59 MHz. i have also tried to export it to ise. i mean there must be a trick somewhere or has nobody used microblaze with ethernet in a spartan 3e yet? any suggestions would be very helpful thanks urbanArticle: 110386
Austin Lesea wrote: > Rick, > > Configuration does not require a "significant amount of energy." > > Not sure where you got that. What exactly does "significant amount of energy" mean to you? In some contexts, the energy to configure certainly would be significant. If it takes 100 ms to configure and the running time is 10 ms, then configuration can clearly be very significant. Of course, if once configured, the FPGA runs for an hour doing very power intensive work the configuration energy is not significant. But then that would not be likely running on a battery, would it? I simply meant that the configuration engery is enough that you need to consider it in context, which I don't think you can argue with.Article: 110387
Austin Lesea wrote: > Rick, > > Configuration does not require a "significant amount of energy." > > Not sure where you got that. He means that during config, there are many clock-buffers active as the whole device configs. Thus config power is certainly likely to be higher than static power, and will also likely be higher than locally clocked functions, with Fclk <= Config speed. Battery Apps are NOT going to run a FPGA at >200MHz all the time! eg I have a Flash-RAM CPLD here, that is appx 200x more Icc during Config load, than static icc. To me, that certainly IS significant. Sure, config does not last long, but you still have to allow for it. That is why you need to decide if (frequent) reloads are worth the gains. Now, a vendor that usderstood this, would put this information in the datasheets, so their customers would be able to make the right design decisions. -jgArticle: 110388
Rick, -snip- > What exactly does "significant amount of energy" mean to you? In this case, if the minimum current required to configure is 200 mA, the current when doing nothing is 100 mA, and the design uses 1000 mA when running, then "significant" is pretty small (100 mA or less). In some > contexts, the energy to configure certainly would be significant. If > it takes 100 ms to configure and the running time is 10 ms, then > configuration can clearly be very significant. Time, yes, but energy, perhaps not? > Of course, if once configured, the FPGA runs for an hour doing very > power intensive work the configuration energy is not significant. But > then that would not be likely running on a battery, would it? In my example above, it still doesn't matter. > I simply meant that the configuration engery is enough that you need to > consider it in context, which I don't think you can argue with. Nope. No argument. It is all in the numbers. Look at the quiescent current, and the min current to configure, and note the delta difference for the part. If that delta is a significant part of the current for the application, then you are correct. If it is not, then it is not an issue. In http://direct.xilinx.com/bvdocs/publications/ds302.pdf pages 5,6,7 the lx60 is 167 mA typical quiescent, and 300 mA typical to configure (actually, to completely power on, clean out and configure). Re-configuration, while the rest of the device is running, should be even less than the min current required, so I am somewhat baffled that you think that this (300-167mA) represents a "significant" amount. Now, if the design takes 200 mA after it is programmed, in addition to the quiescent, then you are absolutely correct: that would be "significant." I suppose that if you have to size the battery, then any extra current could be "significant." AustinArticle: 110389
very valid argument, schematics have this inherent drawback. anyway, i tried to use vhdl but i was unable to get the .bit file and process fails with error "NgdBuild:76 - File "D:\Xilinx\bin\xr16vx\_ngo\xr16vx_1k.ngo" cannot be merged into block "ROOT" (TYPE="xr16vx_1k") because one or more pins on the block, including pin "rs232rx_IPAD_IN", were not found in the file. Please make sure that all pins on the instantiated component match pins in the lower-level design block (irrespective of case). If there are bussed pins on this block, make sure that the upper-level and lower-level netlists use the same bus-naming convention." i am using webpack 8.2i. i have cross checked the port names by converting ngd file to vhdl with ngd2vhdl and port names are exactly the same. but still i am getting above message. any idea where i am wrong? or how can i confirm port names of an edif design file? Duane Clark wrote: > Avion wrote: > > thanks for the help. let me try n i hope it will work. but isn't it > > much easier in schematics to connect signals? is there anyway in > > schematics as well? one way may be to create a schematic of the wrapper > > file u just suggested and then use it. am i right? > > After using half a dozen different schematic packages over a period of > about 20 years, I finally gave up on schematics about 6 years ago. I > like schematics, but they simply are not portable, and you end up having > to keep around an old computer and operating system and schematic > software to support old projects. You really should abandon them; pick > and use an HDL of some. I personally have never used the Xilinx > schematic software, so I can give no help on that.Article: 110390
Avion wrote: > very valid argument, schematics have this inherent drawback. anyway, i > tried to use vhdl but i was unable to get the .bit file and process > fails with error "NgdBuild:76 - File > "D:\Xilinx\bin\xr16vx\_ngo\xr16vx_1k.ngo" cannot be > merged into block "ROOT" (TYPE="xr16vx_1k") because one or more pins > on the > block, including pin "rs232rx_IPAD_IN", were not found in the file. > Please > make sure that all pins on the instantiated component match pins in > the > lower-level design block (irrespective of case). If there are > bussed pins on > this block, make sure that the upper-level and lower-level netlists > use the > same bus-naming convention." > i am using webpack 8.2i. i have cross checked the port names by > converting ngd file to vhdl with ngd2vhdl and port names are exactly > the same. but still i am getting above message. any idea where i am > wrong? or how can i confirm port names of an edif design file? edif files are plain text, so they are easy to check. If your starting file is edif then look there. I have found that the top level entity name in the edif file needs to match the filename (or maybe I have not discovered the right flags to use). That is, if the file is xr16vx_1k.edf, then the top level entity within it needs to be named xr16vx_1k, and that is the name you instantiate within your HDL/schematic. It seems to me that when I have run into that error, it was not really the right location for the error. Check all the signal names and the top level edif entity name.Article: 110391
Austin Lesea wrote: <snip> > I suppose that if you have to size the battery, then any extra current > could be "significant." > > Austin Thanks for recognizing this. If an engineer is considering a situation where a one-week runtime of continuous power-up, run, power-down is desired, every power number and duration in that sequence is part of the overall budget. This is, perhaps, where some engineers are more sensitive than others. I love the idea of a keychain-type device that can do an interesting amount of RF work in tiny bursts but I haven't been brave enough to step into the power analysis to realize the system. I love FPGAs but I recognize there are some things I won't be able to accomplish with them given the realities of the task and silicon at hand.Article: 110392
Austin Lesea wrote: > Rick, > > -snip- > > What exactly does "significant amount of energy" mean to you? > > In this case, if the minimum current required to configure is 200 mA, > the current when doing nothing is 100 mA, and the design uses 1000 mA > when running, then "significant" is pretty small (100 mA or less). > > In some > > contexts, the energy to configure certainly would be significant. If > > it takes 100 ms to configure and the running time is 10 ms, then > > configuration can clearly be very significant. > > Time, yes, but energy, perhaps not? I know you understand the difference between current, time and energy. If the configuration requires more time than the run duration, then it is only reasonable that it will consume significant energy. Using the current values above of 200 mA for configuration and 1000 mA for running with my numbers of 100 ms for configuration and 10 ms for running, the configuration would clearly take more energy than the processing. Of course none of these numbers are real, but they are realistic. The point is it depends on the application. > > Of course, if once configured, the FPGA runs for an hour doing very > > power intensive work the configuration energy is not significant. But > > then that would not be likely running on a battery, would it? > > In my example above, it still doesn't matter. Your example is not complete and of course it matters. > > I simply meant that the configuration engery is enough that you need to > > consider it in context, which I don't think you can argue with. > > Nope. No argument. It is all in the numbers. > > Look at the quiescent current, and the min current to configure, and > note the delta difference for the part. If that delta is a significant > part of the current for the application, then you are correct. If it is > not, then it is not an issue. > > In > http://direct.xilinx.com/bvdocs/publications/ds302.pdf > pages 5,6,7 the lx60 is 167 mA typical quiescent, and 300 mA typical to > configure (actually, to completely power on, clean out and configure). > > Re-configuration, while the rest of the device is running, should be > even less than the min current required, so I am somewhat baffled that > you think that this (300-167mA) represents a "significant" amount. > > Now, if the design takes 200 mA after it is programmed, in addition to > the quiescent, then you are absolutely correct: that would be > "significant." > > I suppose that if you have to size the battery, then any extra current > could be "significant." To be honest I don't get what you are describing. I thought we were talking about a situation where the device was powered down to save energy. Yes, looking back, that is what I said. When there is something to process, the unit would be powered up and the FPGA would have to be configured. This configuration energy is a product of the current and the configuration time. You seem to be talking about something different and completely ignoring the time issues. Regardless of whether the configuration current is a hundred amps or a microamp, if the duration is long enough the energy becomes significant. At a first order of approximation, the configuration energy is significant if the application current-time product is a factor of 10 or less greater than the current-time product for configuration. In other words, the configuration energy is less than 10% or so. There may be applications where the energy wasted in configuration is even more critical as the battery margin is less. Are we talking about different things?Article: 110393
On Oct 14, 10:47 am, "rickman" <gnu...@gmail.com> wrote: > Documentation is often the poor stepchild of a development process.... > > Personally I take pride in the documents I prepare. I never want > anyone to read one of my documents and think it was written by a moron, > even if it was! ;^) Same here. Through the XC3000 and XC4000 generations, I put together every databook, from deciding the format and pagination to writing much of the text, to negotiating the detailed descriptions and even the parameter values. It was pretty much a one-man show. But the parts were simple... Then Xilinx got bigger and various people had to share the "fun". Documenting programmable logic may be more difficult than documenting memories, microprocessors or ASSP dedicated circuits. FPGAs are used in a myriad of ways by hundred thousands of designers with widely varying backgrounds and skills. The person(s) in charge of documentation must be technically savvy in a wide area, be able to write clear and reasonably tight English sentences, have the eyes of an eagle, and the patience of Job. They must be self-confident and persistent without becoming obnoxious, and it helps when they have a respected and senior position in the company, so that they can circumnavigate committees and get things implemented or changed. That's a tough job desciption. No wonder we do not always live up to the highest expectations. But we are still trying... Peter Alfke, Xilinx, fom homeArticle: 110394
Ralphie, let's not sink to kindergarten level. We all can multiply current and time. Most of use even understand percentages... The OP did not give any specific values, and the thread has deteriorated into generalities. Notealso that there are different degrees of powerdown. As long as you maintain Vcc, you have leakage current,which (unfortunately) is significant in state-of-the -art FPGAs. 'nough said. Peter Alfke On Oct 14, 6:34 pm, "ralphie" <ralphmalph_f...@yahoo.com> wrote: > Austin Lesea wrote: > > Rick, > > > -snip- > > > What exactly does "significant amount of energy" mean to you? > > > In this case, if the minimum current required to configure is 200 mA, > > the current when doing nothing is 100 mA, and the design uses 1000 mA > > when running, then "significant" is pretty small (100 mA or less). > > > In some > > > contexts, the energy to configure certainly would be significant. If > > > it takes 100 ms to configure and the running time is 10 ms, then > > > configuration can clearly be very significant. > > > Time, yes, but energy, perhaps not?I know you understand the difference between current, time and energy. > If the configuration requires more time than the run duration, then it > is only reasonable that it will consume significant energy. Using the > current values above of 200 mA for configuration and 1000 mA for > running with my numbers of 100 ms for configuration and 10 ms for > running, the configuration would clearly take more energy than the > processing. > > Of course none of these numbers are real, but they are realistic. The > point is it depends on the application. > > > > Of course, if once configured, the FPGA runs for an hour doing very > > > power intensive work the configuration energy is not significant. But > > > then that would not be likely running on a battery, would it? > > > In my example above, it still doesn't matter.Your example is not complete and of course it matters. > > > > > > I simply meant that the configuration engery is enough that you need to > > > consider it in context, which I don't think you can argue with. > > > Nope. No argument. It is all in the numbers. > > > Look at the quiescent current, and the min current to configure, and > > note the delta difference for the part. If that delta is a significant > > part of the current for the application, then you are correct. If it is > > not, then it is not an issue. > > > In > >http://direct.xilinx.com/bvdocs/publications/ds302.pdf > > pages 5,6,7 the lx60 is 167 mA typical quiescent, and 300 mA typical to > > configure (actually, to completely power on, clean out and configure). > > > Re-configuration, while the rest of the device is running, should be > > even less than the min current required, so I am somewhat baffled that > > you think that this (300-167mA) represents a "significant" amount. > > > Now, if the design takes 200 mA after it is programmed, in addition to > > the quiescent, then you are absolutely correct: that would be > > "significant." > > > I suppose that if you have to size the battery, then any extra current > > could be "significant."To be honest I don't get what you are describing. I thought we were > talking about a situation where the device was powered down to save > energy. Yes, looking back, that is what I said. When there is > something to process, the unit would be powered up and the FPGA would > have to be configured. This configuration energy is a product of the > current and the configuration time. You seem to be talking about > something different and completely ignoring the time issues. > > Regardless of whether the configuration current is a hundred amps or a > microamp, if the duration is long enough the energy becomes > significant. At a first order of approximation, the configuration > energy is significant if the application current-time product is a > factor of 10 or less greater than the current-time product for > configuration. In other words, the configuration energy is less than > 10% or so. There may be applications where the energy wasted in > configuration is even more critical as the battery margin is less. > > Are we talking about different things?Article: 110395
Peter Alfke wrote: > Ralphie, let's not sink to kindergarten level. We all can multiply > current and time. Most of use even understand percentages... > The OP did not give any specific values, and the thread has > deteriorated into generalities. > > Notealso that there are different degrees of powerdown. As long as you > maintain Vcc, you have leakage current,which (unfortunately) is > significant in state-of-the -art FPGAs. > 'nough said. > Peter Alfke What's up with you? No one's gotten offensive until you made the kindergarten comment. From his post it is clear that he is missing something about the problem being stated. I didn't get offensive about this. I just explained with plenty of detail to clear up the point of confusion. Of course it is possible that you don't want to clarify the point of confusion, I can't say. But I don't get what you mean when you say "there are different degrees of powerdown". Power down to me has always meant *no* power. Is there some other power state that is called "powerdown" that I don't know about? How do you mean the term? If you maintain Vcc, why would you need to reconfigure the FPGA? What is going on here? I am just trying to discuss a technical issue. Don't get your knickers in a knot!Article: 110396
No knickers in a knot (interesting analogy). I was just tired of the endless repetition of very simple calculations. Regarding power-down: Some people think that sleep mode or idle mode means powerdown (which it did, 10 years ago. Today you really have to lower Vcc to a very low value in order to save the leakage current.) But now I also sank to the kindergarten level. Just because this is a newsgroup, we do not need to repeat the same simple statements ad nauseam. Peter Alfke On Oct 14, 7:01 pm, "ralphie" <ralphmalph_f...@yahoo.com> wrote: > Peter Alfke wrote: > > Ralphie, let's not sink to kindergarten level. We all can multiply > > current and time. Most of use even understand percentages... > > The OP did not give any specific values, and the thread has > > deteriorated into generalities. > > > Notealso that there are different degrees of powerdown. As long as you > > maintain Vcc, you have leakage current,which (unfortunately) is > > significant in state-of-the -art FPGAs. > > 'nough said. > > Peter AlfkeWhat's up with you? No one's gotten offensive until you made the > kindergarten comment. From his post it is clear that he is missing > something about the problem being stated. I didn't get offensive about > this. I just explained with plenty of detail to clear up the point of > confusion. > > Of course it is possible that you don't want to clarify the point of > confusion, I can't say. But I don't get what you mean when you say > "there are different degrees of powerdown". Power down to me has always > meant *no* power. Is there some other power state that is called > "powerdown" that I don't know about? How do you mean the term? If you > maintain Vcc, why would you need to reconfigure the FPGA? > > What is going on here? I am just trying to discuss a technical issue. > Don't get your knickers in a knot!Article: 110397
ralphie wrote: <snip> > Are we talking about different things? For some ideas on what "power down" might consist of, take a look at the power discussions in the Spartan-3L data sheet. While the idea of a low-power FPGA initially piqued my interest, the method of "deep hibernation" (or some similar term) where the configuration is lost but still some power is used seemed to me a bit bizarre but this functionality might be critical in a system that needs other (milliamp) devices operating continuously without the VCCINT==0 FPGA bringing down the system. With the VCCINT==keeperVoltage, the I/Os might now behave nicely without the full-voltage quiescent power of the FPGA. Outside of the 3L data sheet (and possible application notes or TechXclusive articles thereof) there isn't a great deal of "low power" discussions in the Xilinx literature for modern FPGAs that I'm aware of. If nothing else, the 3L information can broaden your ideas on possible power-down (or power-saving) scenarios. - John_HArticle: 110398
ralphie, Perhaps I am missing something? Rick mentioned "significant" penalty for reconfiguring, and I pointed out that a few hundred mA (at the most) is all we are talking about. It is up to the engineer to decide if a few hundred mA is significant, given the benefit (don't reconfigure, need a larger part with more leakage, do reconfigure, and you can potentially use a much smaller part, more efficiently). No one mentioned turning things off, or "sleep" modes as far as I know. Really very simple, and very straightforward. If you also bring into the mix just turning everything off, then doing anything at all, other than leaving everything off, that is infititely "significant" (anything more than 0). AustinArticle: 110399
u_stadler@yahoo.de wrote: > hi > > well thanks for all the answers so far. > i 'm still trying to get some more speed out of edk. > well as said before i'm not doing anything fancy. just straight forward > stuff and i was wondering what good the ethernet core is if i can't get > it to synthesize with more than 59 MHz. i have also tried to export it > to ise. i mean there must be a trick somewhere or has nobody used > microblaze with ethernet in a spartan 3e yet? > any suggestions would be very helpful > > thanks > urban > I was pretty sure someone recently had just that running on the spartan-3e starter board. Uclinux with networking and I think it was microblaze. Look in the archives, like in the last 1-2 months. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architecture
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