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
Your examples show exactly the difference between sync & async resets. Your 1st process will reset on the input, regardless of what the clock is doing. The synthesiser will use an asynchronous reset, if it's available. If it isn't, synthesis will (should?) fail. Similarly, the 2nd process is synchronous, with clock governing reset. The synthesiser will use a synchronous reset, if it has one. If not, it will usually create one, by adding an AND gate right at the flipflop's input. If you have gone to the trouble of synchronising your async reset input, then use the 2nd case. In fact, you should always (imho) do it this way, ie synchronise the reset input *once*, then feed it to everything. If the reset load is large, use a tree of intermediate flipflops to fan-out the (synchronised) reset signal across your chip. This strategy ensures that everything starts on the same clock edge. If you use an asynchronous reset to many flipflops around the chip, it's a certainty that some will exit reset before a given clock edge, and some after. That can be very bad juju :-) ALuPin@web.de (ALuPin) wrote: :Hi @ all, : :it is one possibility to :synchronize an asynchronous reset so that all flip flops in :the FPGA are resetted within the same clock period. : :Using this synchronized reset :can I still write the process like that: : : :process(Sync_reset, Clk) :begin : if Sync_reset='1' then : ... : elsif rising_edge(Clk) then : ... : end if; : :end process; : :or does it make more sense to write it like that: : :process(Sync_reset, CLk) :begin : if rising_edge(Clk) then : if Sync_reset='1' then : ... : else : ... : end if; : end if; :end process; : :I would be very thankful for your opinion. : :Rgds :AndréArticle: 75101
Hello, I am facing a problem with Dual-Port RAM (specifically RAM: 2 Port) Megafunction in Quartus 4.0 version, which seems to be a common one. Given the width of the word and number of words is immaterial, my parameters are as follows: -RAM registers output port q. -It is set to 'Auto'. -The other input and output ports and their settings are as follows: Input Ports: 1. Data: arrives at frequency 'a' or time period 'x'. 2. rden: starts at rising edge and has frequency 'a' or time period 'x'. 3. wren: starts at falling edge and has frequency 'a' or time period 'x'. It is invert of rden. 4. wraddress and rdaddress: are associated with the same counter (since my application requires reading old data and writing new data simultaneously in one data clock cycle) and change at the same frequency 'a' as of data cycle. Infact, I am serially reading/writing the memory contents, so the counter increments by one at any time. 5. rdclock and wrclock: both start at falling edge and have frequancy '2a' or time period 'x/2'. Output Port: 1. q In such cases, the delay in reading at output comes out to be '3x/4'. But I want this delay to be wither 0 or n*x/4 where n is even integer. How is this possible? Thanx in advance.Article: 75102
Bill wrote: > To get repeatable > performance I had to resort to 2-phase clocking for local clocks. What do you mean by that? Could you give more details? Rgds AndréArticle: 75103
Symon wrote: > All, > > After reading and contributing to a few interesting threads recently > about PCBs for FPGA designs, I thought I'd post about the technology > I've been using for the past 3-4 years. My job involves getting a lot > of high density circuitry into a small space, and so awhile back I > decided to use microvias (laser drilled vias) to pack more stuff onto > my boards. The surprising thing was that the boards worked out > cheaper for my application than if I hadn't used this method. Where do you get your prototype boards fabbed?Article: 75104
Somebody can send an example, document or advice to help me in the verilog implementation of a OPB module (EDK 6.2) thanks, -- AndresArticle: 75105
Ray, Yes, it just goes to show that you have to make some measurements to really discover everything. Austin Ray Andraka wrote: > Faster and smaller generally comes out a little ahead of larger slower in my > experience. The trade off between clock speed and area is more or less a wash > because power is proportional to clock frequency, however there are second > order effects to consider. First, a smaller design means the routing can be > more localized. Routing distance is roughly proportional to the square root of > the area. Secondly, a parallel design, at least for arithmetic has extra > routing orthogonal to the signal path and extra gating to handle the carry > functions. This extra logic and associated routing makes the v-F curve > non-linear. > > Austin Lesea wrote: > > >>Hal, >> >>Let's see....P= CV^2F, and so for each node switching, the power scales >>with frequency. >> >>One node at F is equal to two nodes at 1/2F? Yes, it sure looks that way. >> >>I suppose the reason to run slower is to run cooler. >> >>But, you are right, run the smallest part as fast as needed to do the work. >> >>No reason to run it any faster than needed, however. >> >>One reason for the very low power for the DSP48 is that the capacitive >>loads are very small. >> >>Good catch. >> >>Thanks, >> >>Austin >> >>Hal Murray wrote: >> >> >>>>FPGAs are very efficient for doing the work (dynamic power), but high >>>>clock speeds means lots of power. Better to make the algorithm highly >>>>parallel, and lower the clock rate as much as possible. >>> >>> >>>What's going on here? Classic reasoning says that 2 FFs at half >>>speed will take the same power as 1 FF at full speed. (assuming >>>same cap load...) >>> >>>Why not run faster so you can use a smaller part and get lower >>>static power? >>> > > > -- > --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 > >Article: 75106
Jim, Vccaux is required, as is Vcco for the config bank. There is the Power On Reset control circuit wired to these three supply sources. If the POR trips going low, then memory is zeroized when POR comes back up (On). The static Icco is pretty low, I think less than 2 mA per bank (at 3.3V, less at a lower Vcco). Still gathering data on that for the data sheet. The proposal I heard (from one engineer) was to run all LVDS IO, with a few 2.5 V 2 mA CMOS single ended IOs for things like LEDs, switches, slow peripherals (like the power controller). Turns out that LVDS IOs are constant 4mA each (hi or lo), so single ended IOs would be much more efficient (but slower). The idea was to also go to the abs min voltages allowed for the sleep mode (e.g 1.0V), and the recommended mins for operation. If that did not do it, they wanted to know if we would consider a test program to verify even lower sleep and operating voltages. Good news is that the V4 is the most CMOS'sy chip we have had in awhile -- it really works well at lower voltages int eh interconnect, CLB and other simple functions. The complex functions (MGT, DCM, PPC) are not likely to be as forgiving if run out of spec. As I said before, test programs are just money, so if it is worthwhile, then it is considered. We just need to be sure that we can yield reliably to the screen, and it makes business sense to do it. It would not do anyone any good if the screen suddenly stopped yielding any parts due to a small process shift. Such screens are never entered into lightly, and require a great deal of work (hence the reason why there is usually a large volume involved). Often as we gain more data from a new part, we may change specifications (expand the operating ranges, speed up paths, etc.) so we will have to wait. Austin Jim Granville wrote: > Austin Lesea wrote: > <snip> > >> >> There is also Vccaux (Iccaux) at 2.5V, and Vcco at ??V to consider as >> well. > > > Only some devices have Vccaux - can that be removed, or does it need to > be reduced ? > Vcco I presume can be removed on selected banks, if you realled needed > to, but the Static Icc on IO cells should be very low, as they are > relatively few - correct ? > > -jg >Article: 75107
Symon wrote: > > Rick, > I typically save about 4 to 6 layers by using microvias. My boards go into > hand-held portable equipment so board space is at a premium, which is why > the boards are so dense. > To answer your question, in my experience, you would certainly be able to > convert a ten layer conventional board to eight layer microvia board. > > 1) signal > 2) signal > 3) ground > 4) signal > 5) signal > 6) ground > 7) signal > 8) signal > > Microvias between layers 1 and 2. Power routed with localised split planes. > > To suggest anything further, it depends on what size FPGAs/BGAs you're > using. Are you willing and able to swap a lot of pins around on the FPGA to > route to the other devices on your board? How many of the 10 layers you > currently use are power/ground planes? > Cheers, Syms. The current board uses one ground, one power, split with some extra power traces running on a signal layer. I had been planning to keep that the same. Sounds like you are suggesting two ground layers and another for power, no? Do you have a ball park number for the additional cost of microvias? I guess I would need to plug that into some quote web pages to see. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 75108
>> http://www.altium.nl/corp/media/pdfs/20041025_altium_mr_jtag_cable.pdf it is a litle funny it is rated to 49$ in this file, know it is rated to 99$ and in the EU to 99? KasperArticle: 75109
Symon, Awesome. Great posting. We have recently begun using buried vias (fully internal vias blind to both sides). I do not know if these are laser drilled, or not. The cost was not a factor. It is imperative to use this technology for the 10Gbs transceivers (for better matching), as just one example of their need. As well, it has all of the other benefits you detail (regarding having better overall SI due to less "swiss cheese"). AustinArticle: 75110
Hi Folks, Is it possible to send user commands through JTAG to the internal Logic in the FPGA ? More Specifically a Spartan 3 FPGA. Thanks, PrashanthArticle: 75111
Ivan, The JTAG is powered from the 2.5V Vccaux. Austin Ivan wrote: > Hi, > > Did anyone know what is the Xilinx recommended pull-up register value > for the JTAG configuration pins (TCK, TMS, TDI, TDO and M0-M2) for > Virtex4? > > Thanks, > IvanArticle: 75112
>So, out of curiosity, how would you do it if the BiPhase clock was around >80MHz ? (ideally Spartan 2 based) I don't have any great answers. How clean is your input signal? How many samples per bit do you need to get a reasonable result? You can push the FSM technology a factor of two or maybe 4 by having a front end that goes x times as fast and feeding multiple bits into the FSM on each clock tick. The general idea is similar to processing several bits per clock in a CRC. Same basic algorithm but much more logic to implement it. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 75113
Oops, hit return too soon. See page 554 of the User's Guide. See note 1. Active pullup to Vccaux (2.5V) Austin Austin Lesea wrote: > Ivan, > > The JTAG is powered from the 2.5V Vccaux. > > Austin > > Ivan wrote: > >> Hi, >> >> Did anyone know what is the Xilinx recommended pull-up register value >> for the JTAG configuration pins (TCK, TMS, TDI, TDO and M0-M2) for >> Virtex4? >> >> Thanks, >> IvanArticle: 75114
eliben@gmail.com wrote: > > Hi all, > > When synthesizing my design with Quartus v4.0, I noticed that a > critical time path (after optimizations for timing) was in the > following process: > > process (clk, reset) > begin > if (reset = 1) > data_reg <= (others => '0'); > elsif (rising_edge(clk)) > for i in 0 to 24 loop > if (byte_cnt = i) then > data_reg <= frame(i * 8 + 7 downto i * 8); > end loop; > end if; > end process; > > The assignment to data_reg ran too slow. It figures that this is > slow because it contains a large mux. A colleague suggested to replace > the "for" with an explicit if..elsif of 25 clauses. I said > "no way" - it's the same, and Quartus should be smart enough to figure > it out. Surprise ! Quartus isn't. When I indeed changed > to a full if..elsif list (unrolled the for loop), the path shortened by > a few ns. Dire dissapointment, because the "for" code > is nicer, maintainable and extensible... The 25 clause if...elsif is > clinky, big and prone to bugs. > > Has anyone run into a similar problem and/or has some insights how to > handle this ? Why isn't it trivial for Quartus to figure out ? I don't know about the efficiency, but why do you need a loop to describe this mux? Can't you just use byte_cnt directly in your assignment to data_reg? data_reg <= frame(byte_cnt * 8 + 7 downto byte_cnt * 8); I found an example of this in a Ben Cohen book, so I assume it works. Does it not synthesize? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 75115
All, Hold that thought. The users guide is confusing (???). In one section it states "open drain" and in another, it states "active pullup." Will post as soon as I know, Sorry for the confusion. AustinArticle: 75116
Mike Harrison wrote: > > On Tue, 26 Oct 2004 03:21:05 -0500, hmurray@suespammers.org (Hal Murray) wrote: > > >>How can we extract clock from bi-phase encoded data (3.072Mbps - > >>AES/EBU Data) using CLKDLL of Xilinx FPGA. The clock should be able to > >>adjust itself to any slight drifting of the bi-phase data. > > > >3 MHz is slow. Just build a FSM that parses the data stream. > >Say with a 10x or 16x clock. > > > >Experiment a bit with some graph paper if you haven't done it before. > >It will be obvious when you see it. > This works for pure data extraction, but no good for audio apps where you need to produce a > jitter-free clock for an output stream locked to the input rate. Actually, this will work pretty well. Since no clock is "jitter-free" there is a tolerance. The FSM clock needs to be fast enough to be within the tolerance. The result will be data and a clock that is aligned with the incoming signal within the tolerance. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 75117
>This works for pure data extraction, but no good for audio apps where you need to produce a >jitter-free clock for an output stream locked to the input rate. Thanks. How much jitter can an audio system tolerate? Is it reasonable to use digital clock synthesis techniques? If so, how fast a clock do I have to start with? Is the answer different for phone quality vs hi-fi systems? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 75118
ISE Eval includes all ISE tools (but does not include System Generator, EDK, or ChipScope) and has a 60 day timeout. The WebPACK does not time out, but is for the smaller devices and does not include CoreGen and FPGA Editor. The 6.3i WebPACK does not support the 4VLX25 which is on the ML401. Steve rickman wrote: >Tommy Thorn wrote: > > >>austin wrote: >> >> >>>Pete, >>> >>>Got it. >>> >>>Will take it from here. >>> >>>Thanks. >>> >>> >>.... >> >> >>>>The ML401 is a cool looking Virtex 4 development board made >>>>and sold by Xilinx. I should have one on Monday or Tuesday. >>>> >>>> >>While we're waiting for the sources, could someone fill me in on the >>details on the "Evaluation versions of Xilinx tools" mentioned at the >>button of >>http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?sSecondaryNavPick=Design+Tools&iLanguageID=1&category=&key=HW-V4-ML401-USA&sGlobalNavPick=PRODUCTS&BV_SessionID=@@@@1661231197.1098759200@@@@&BV_EngineID=cccfadcmlffdfmfcflgcefldfhndfnf.0 >>Ie., what can I do with that and how does it differ from the >>non-evaluation tools (and from the free WebPACK)? >> >>The ML401 is a very impressive kit - IMO it sets a new bar for >>development kits. >> >> > >I don't remember the details, but the webpack tools only cover the low >end parts, but do not expire. The eval version is one of the full ISE >packages, but is only licenced for 30 days. Webpack also has some >features missing such as chip editor, etc. > > >Article: 75119
Ben Twijnstra wrote: > Hi Eliben, > > > When synthesizing my design with Quartus v4.0, I noticed that a > > critical time path (after optimizations for timing) was in the > > following process: > > > > process (clk, reset) > > begin > > if (reset = 1) > > data_reg <= (others => '0'); > > elsif (rising_edge(clk)) > > for i in 0 to 24 loop > > if (byte_cnt = i) then > > data_reg <= frame(i * 8 + 7 downto i * 8); > > end loop; > > end if; > > end process; > > > > The assignment to data_reg ran too slow. It figures that this is > > slow because it contains a large mux. A colleague suggested to replace > > the "for" with an explicit if..elsif of 25 clauses. I said > > "no way" - it's the same, and Quartus should be smart enough to figure > > it out. Surprise ! Quartus isn't. When I indeed changed > > to a full if..elsif list (unrolled the for loop), the path shortened by > > a few ns. Dire dissapointment, because the "for" code > > is nicer, maintainable and extensible... The 25 clause if...elsif is > > clinky, big and prone to bugs. > > The constructs are NOT the same. In the loop example you infer a latch > situation in case byte_cnt is not between 0 and 24, which Quartus will > cater for. In the unrolled version you made I am 99.9999% sure that it ends > with > > elsif byte_cnt = 23 then > data_reg <= blablabla; > else -- Note: no elsif!!! > data_reg <= hohohoho; > > Thus, you also define a value for data_reg for values of byte_cnt for values > 25 and up, which is not what you do in the loop. A simple solution would be > to add a default assignment for data_reg, as such: > > process (clk, reset) > begin > if (reset = 1) > data_reg <= (others => '0'); > elsif (rising_edge(clk)) > data_reg <= frame(7 downto 0); -- not the same but saves a lot of typing > for i in 0 to 24 loop > if (byte_cnt = i) then > data_reg <= frame(i * 8 + 7 downto i * 8); > end if; > end loop; > end if; > end process; > > I'll give it a try. Thanks ! EliArticle: 75120
rickman wrote: > eliben@gmail.com wrote: > > > > Hi all, > > > > When synthesizing my design with Quartus v4.0, I noticed that a > > critical time path (after optimizations for timing) was in the > > following process: > > > > process (clk, reset) > > begin > > if (reset = 1) > > data_reg <= (others => '0'); > > elsif (rising_edge(clk)) > > for i in 0 to 24 loop > > if (byte_cnt = i) then > > data_reg <= frame(i * 8 + 7 downto i * 8); > > end loop; > > end if; > > end process; > > > > The assignment to data_reg ran too slow. It figures that this is > > slow because it contains a large mux. A colleague suggested to replace > > the "for" with an explicit if..elsif of 25 clauses. I said > > "no way" - it's the same, and Quartus should be smart enough to figure > > it out. Surprise ! Quartus isn't. When I indeed changed > > to a full if..elsif list (unrolled the for loop), the path shortened by > > a few ns. Dire dissapointment, because the "for" code > > is nicer, maintainable and extensible... The 25 clause if...elsif is > > clinky, big and prone to bugs. > > > > Has anyone run into a similar problem and/or has some insights how to > > handle this ? Why isn't it trivial for Quartus to figure out ? > > I don't know about the efficiency, but why do you need a loop to > describe this mux? Can't you just use byte_cnt directly in your > assignment to data_reg? > > data_reg <= frame(byte_cnt * 8 + 7 downto byte_cnt * 8); > > I found an example of this in a Ben Cohen book, so I assume it works. > Does it not synthesize? I'm not sure about synthesis, but Modelsim doesn't eat it - it wants a constant expression in the array indices. I tried it before I created the "for" hack, it didn't compile. EliArticle: 75121
David R Brooks wrote: > > Your examples show exactly the difference between sync & async resets. > Your 1st process will reset on the input, regardless of what the clock > is doing. The synthesiser will use an asynchronous reset, if it's > available. If it isn't, synthesis will (should?) fail. > > Similarly, the 2nd process is synchronous, with clock governing reset. > The synthesiser will use a synchronous reset, if it has one. If not, > it will usually create one, by adding an AND gate right at the > flipflop's input. > > If you have gone to the trouble of synchronising your async reset > input, then use the 2nd case. In fact, you should always (imho) do it > this way, ie synchronise the reset input *once*, then feed it to > everything. If the reset load is large, use a tree of intermediate > flipflops to fan-out the (synchronised) reset signal across your chip. > This strategy ensures that everything starts on the same clock edge. > If you use an asynchronous reset to many flipflops around the chip, > it's a certainty that some will exit reset before a given clock edge, > and some after. That can be very bad juju :-) There is a reason that the reset is async. If your clock goes away, you will not be able to reset the circuit with a purely synchronous reset. I normally use a combination, not in the entire chip, but on the critical portions. For example, I don't care how a data register powers up or what its timing is. But a FSM is important to power up correctly. But even then, not every FF has to be released at the same clock. If it is a one hot FSM, I use a two or three state init sequence that leads into my "normal" start state. This gives the async reset two or three clock cycles to propagate and release the rest of the FSM. If you try to provide a sync reset to the entire chip in one clock cycle, you can burn a lot of routing resources and limit your clock speed. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 75122
6.3i service pack 2 included the larger Spartan3 devices, so even WebPACK customers will have access to those devices. The 7.1i WebPACK will not include the 3S2000 and 3S4000. Steve Eric Smith wrote: >"John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk> writes: > > >>I think you will find that you need to do a web install at present to get >>all the devices. >> >> > >That wasn't the question. The OP was referring to the fact that >the downloadable WebPACK 6.3i is stated to support Spartan 3 up to >XC3S1500, yet he says that the pull down menu included the 2000 and >4000 as well. > >The ISE 6.3i evaluation and BaseX installations from CD apparently >only suuport Spartan 3 up to XC3S400. > >I haven't confirmed any of this personally. I'm using the downloaded >WebPACK 6.3i for XC3S200 designs (using the Spartan 3 Starter Board), >and it works fine for that. > >Article: 75123
Hi Simon, A few comments included below, but do we agree that saying "FPGA's by their very nature are low power.. provided you don't clock them fast." is somewhat misleading? Cheers, Syms. "Simon Peacock" <nowhere@to.be.found> wrote in message news:417e23a9@news.actrix.gen.nz... > Forget a V2PRO... unless you need a power PC... there are far cheaper > options to get a processor. > > I also never suggested using bleeding edge... if you pick an 'older part' > you will find the static current better... it just won't have the same > capability as the modern 90 nm parts.. although cyclone (cough cough) seem > to have a lower quiescent current 12mA - 80 mA.. but they probably cheated > to get that. The V2PRO I mentioned doesn't have a PowerPC, but anyway I'd question whether V2PRO is bleeding edge. (Bleeding irritating, maybe!) Anyway, even small plain old Virtex (50mA) and SpartanIIe (200mA) suffer from this Iccintq problem. I'll check out the A parts, thanks for the pointer. > > And even tho A or X seems good what about Q ? > Quicklogic Eclipse is a low power (not so) FPGA .. so they might be via > OTP... so you prototype with RAM based... but you can't beat the 22 - 250 uA > quiescent current... and only 100mA at 100Mhz. Sounds like a good solution. > > Don't forget the option of powering down when not in use, use a coolrunner > to turn the FPGA off if necessary / possible just don't forget to shut down > I/O too.. or the saving will be killed by protection diodes. > Older FPGA's have smaller configurations and can be programmed fast if you > externally clock them. > So, if the CPLD/FPGA you're powering down has live inputs from other places, won't these inputs back power the part through the protection diodes? So, the inputs have to be off too? > And yea.. design to typical.. select of test even :-) unless your running You bad boy! I'd never do that. (= I'd never admit to doing that!) ;-) > > at -20 or +60C .. but at 0C you NiMH battery life will be half that at 20C > too.. > Then pick a better battery... heard of lithium ion? :-) What do you mean by better? Price? Also, Lion and NiMH have the same(ish) volumetric energy density. Are Lions better over temperature? Is self discharge better in Lions? (Sounds like a sticky mess in the Serengeti!) > You might also want to watch the D cells.. often the are a 'C' cell in side > a cardboard wrapper. There are also special 'radio modeller' NiCAD's that > have rather nice mAH ratings... designed for electric cars and planes. > I thought these special NiCds were high power cells, not high energy? > I have a battery pack here good for 600mA hours @ 8.4V... not much bigger > than a D cell. Which is why it has the same(ish) energy storage as a NiMH D cell! 6.5Ah @ 1.2V. http://www.panasonic.com/industrial/battery/oem/ > > Simon > > > > "Symon" <symon_brewer@hotmail.com> wrote in message > news:2u4nrqF26i2edU1@uni-berlin.de... > > Simon, > > I guess it's been a while since you checked out the quiescent supply > > currents for the latest parts? For example, worst case Iccintq for the > > smallest V2PRO (XC2VP2) is 300mA. That's about 20 hours on a NiMH D cell. > > Typical is 20mA, but no-one would design with typical figures, would they? > > BTW, anyone know why there's such a big difference from 'typical' to 'max' > > figures? Does it depend on the configuration used in the part? > > Cheers, Syms. > > > > "Simon Peacock" <nowhere@to.be.found> wrote in message > > news:417cd164@news.actrix.gen.nz... > > > FPGA's by their very nature are low power.. provided you don't clock > them > > > fast. > > > > > > > > > > >Article: 75124
Steve Lass <lass@xilinx.com> wrote: > 6.3i service pack 2 included the larger Spartan3 devices, so even > WebPACK customers will have access > to those devices. The 7.1i WebPACK will not include the 3S2000 and 3S4000. Ah so it *was* a screw-up and those devices were never intended to be included then? :-) G.
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