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
Kenneth, Comments added. "Kenneth Land" <kland_not_this@neuralog_not_this.com> wrote in message news:10ns44e65o5gp31@news.supernews.com... > > Symon, > > What are the speeds of your clocks and signals both within your FPGA and > external? I use 600+MHz clocks and > 600+Mbit data to and from the FPGA. I always use the 'divide-by-two' DCM thing and DDR IOBs for this. There's also 2.5 GHz/Gbps in some places on some boards, not to the FPGA of course. I've not tried the Rocket I/Os yet, although they are wired up on a couple of boards. > Are you getting and passing EMI compliance testing? Yes. Most of the problems come from inter board connections. I'm trying to move to using the Rocket I/Os for this. The microvias are a big help for getting termination resistors right where you want them. I use packs of 2 (1mm square) and 4 (2mm x 1mm) resistors for this, with vias in the pads. > Have you tried or considered using thin layers between power (also signal in > your case) > and ground planes instead of or in addition to bypass caps? No. I reasoned that the tiny amount of (admittedly v. high Q) capactitance you gained by doing this is pissed away by the inductance of the vias, tracking, balls, and tracking on the FBGA substrates. > Do you do SI/EMI simulations or just build these boards? :) HyperLynx is my friend! Or it would be if I could get IBIS models of the LVDS_DT inputs! When I mentioned earlier that I've had EMI problems with interboard connections, I had a processor address and data bus from another board that connected to a V2PRO. By the time the 3.3V signals got to my FPGA, I had overshoot to 5.5V and undershoot to -2V before the diodes clamped the signals. The uP board designer had used sub-ns buffer-drivers from IDT to drive the 50MHz bus over a 2mm pitch connector. (Those IDT buffers, they're really quick!) So, demonstrating to the guy who spends the R&D cash, I lifted the power pins to the IDT parts and put 50 Ohm resitors in series. The overshoot vanished, leaving the undershoot unchanged. When I put resistors in series with the ground pins of the IDT buffers, the undershoot went as well. When I used HyperLynx to model the system, I got the same results. Purchase Request for HyperLynx was signed! > > Thanks for sharing this! Awesome stuff! > > Thanks, > Ken > >Article: 75126
Hi Sylvain, Comments below! Best, Syms. "Sylvain Munaut" <tnt_at_246tNt_dot_com@reducespam.com> wrote in message news:417e148b$0$7082$ba620e4c@news.skynet.be... > What's the diameter/restring of micro vias ? Hole is 6mils, land is 14. 150um and 350um in new money. ;-) > I don't see them in the 'capabilities' of the pcb supplier I'd like to use. > They however have blind vias with hole diameter down to 50µm. I guess that > would work. > > > What is warpage btw ? > It's a made up word that means how much the board warps or bends after, or even during, reflow and the like. Too much prevents the devices soldering properly, which is why the datasheets always have a coplanarity spec. for the pins. I guess BGAs are probably less affected by this than QFPs > > > SylvainArticle: 75127
it is.Article: 75128
Hi Tim, These guys helped me develop this stuff. Highly recommended, intelligent and open to trying out new stuff! And they also used to beat us every year in the annual inter-company cricket match! http://www.graphic.plc.uk/ I've since moved jobs/continents, so I now use http://www.ddiglobal.com HTH, Syms. "Tim" <tim@rockylogic.com.nooospam.com> wrote in message news:cllk8q$jnl$1$8300dec7@news.demon.co.uk... > > Where do you get your prototype boards fabbed? >Article: 75129
"David Brown" <david@no.westcontrol.spam.com> writes: > The x86 architecture is propritery, > or "closed" - you need a license to be able to make an implementation. Since when? Are you asserting that the IIT, Nexgen, Rise, and Transmeta x86 designs were licensed by Intel?Article: 75130
Ivan, From the designers: "VCCO_0 can be powered with 2.5V or 3.3V and the JTAG interface will work at that voltage. there is no need for any pull ups or supporting resistors on these pins. the user's guide will be fixed because it is plainly misleading." Thanks for finding this for us! 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: 75131
Rick, Comment below. Cheers, Syms. "rickman" <spamgoeshere4@yahoo.com> wrote in message news:417E75DB.8503C550@yahoo.com... > > 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? > Yes, once I saw all these different core and I/O supplies appearing, I decided to concentrate on the ground layers and track/local-plane the powers. It also makes analysing the SI stuff a lot easier, because there's always a nearby ground plane for every signal's return current to travel along. Check out http://www.sigcon.com/Pubs/news/6_04.htm for an example. Sounds like your board is already very busy wrt signal layers. Must be pretty dense. > 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. > Yeah, the cost depends on so many things. You've gotta work with your PCB house to work out what's best. I guess what I'm trying to say is that by spending on the laser vias, you save on the layers. Another point is that cheap overseas PCB fabs often can't produce these boards. They're geared up for mass produced boards. But your local PCB company can. So sometimes, for the right application, you end up with a cheaper board, produced locally with all those support, turn-around time, quality benefits that brings while keeping the bean-counters happy too... Cheers, Syms.Article: 75132
Dave, Check out XAPP224 from Xilinx. http://www.xilinx.com/bvdocs/appnotes/xapp224.pdf Might give you some ideas! Cheers, Syms. "Dave Garnett" <dave.garnett@metapurple.co.uk> wrote in message news:417e3339$1_1@127.0.0.1... > > So, out of curiosity, how would you do it if the BiPhase clock was around > 80MHz ? (ideally Spartan 2 based) > > Dave >Article: 75133
KVP 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. > > Hi KVP, I am working on something similar. You cannot use the 48MSPs to recover your clock in the DLL because the sync patterns have a bi-phase violation. The lowest clock you can recover is 64 / 4 * 48kHz = 768kHz. This is too slow for that fast DLL. One solution I thought about was switching the DLL input to its output while sync. But what is on transmission errors? Your DLL will go out of control. My intention is using a 32.768MHz VCXO and a FIFO. The VCXO is FLLed to the recovered input. So you use the AES syncs to FLL to your clock. See also the thread "VCXO emulation" in this NG. Regards ThomasArticle: 75134
pierrotlafouine@hotmail.com (Pierre Lafrance) wrote in message news:<d77de4d1.0410210743.5db6ce79@posting.google.com>... > How long it took you to get used to Handel-C language, feel confident in > the code you write ? > > Thanks upArticle: 75135
Not really. It was a conscious decision to avoid having to provide 2 different service packs. Steve Gavin Scott wrote: >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. > >Article: 75136
eliben@gmail.com wrote in message news:<1098778698.183224.270780@z14g2000cwz.googlegroups.com>... > [...]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. [...] Another reason the for loop isn't equal to if..elseif: The for loop checks the variable against the loop value for every iteration of the loop reguardless fo past equality, like a series of ifs without any elseifs. You need to break out of the loop inside the if statement to make it similar to if..elseif. At least, I think I read something like that on here before. I don't know enough about it yet to be sure that I'm remebering correctly. -ExtrariusArticle: 75137
Austin Lesea wrote: > Jim, > > Vccaux is required, as is Vcco for the config bank. Power of VccAux ? Are you saying Non-config banks can be Vcco removed, if desired ? [eg a DRAM interface could de-power the DRAMS, and their Banks ?] > > 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. This is sounding a good direction, similar to Mobile Pentiums/Athlons. There are SMPS devices with quite wide binary control of Vout, designed for the CPU markets. Also, devices like the new LTC6905 http://www.linear.com/pc/productDetail.do?navId=H0,C1,C1010,C1096,P7888 also has power-save promise, by clock-vary 17:170MHz at reasonably low power levels. Most small micropower uC have clock-out options, that can also be used if some portion of the FPGA needs to 'tick-over' - I think from what you are saying, that the complex blocks, DLLs etc do not work as low as the logic fabric, and config SRAMs - so something like an LCD interface, or a keypad scan could run at < 1MHz at the lower Vccs ? [ that would allow users to choose between a really small uC, and some sytem IO in the FPGA, or a larger uC with more pins, and more agressive power-removals on the FPGA. ] -jgArticle: 75138
Jim, Yes, if all you want to do is 'sleep', you can remove power from the Vcco banks other than the one with the POR circuit on it. The intrinsic protection diodes are always there, so if other circuits are powered, you may end up powering the Vcco of the banks through the diodes. Austin Jim Granville wrote: > Austin Lesea wrote: > >> Jim, >> >> Vccaux is required, as is Vcco for the config bank. > > > Power of VccAux ? > Are you saying Non-config banks can be Vcco removed, if desired ? > [eg a DRAM interface could de-power the DRAMS, and their Banks ?] > >> >> 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. > > > This is sounding a good direction, similar to Mobile Pentiums/Athlons. > There are SMPS devices with quite wide binary control of Vout, designed > for the CPU markets. > > Also, devices like the new LTC6905 > http://www.linear.com/pc/productDetail.do?navId=H0,C1,C1010,C1096,P7888 > also has power-save promise, by clock-vary 17:170MHz at reasonably low > power levels. > > Most small micropower uC have clock-out options, that can also be used > if some portion of the FPGA needs to 'tick-over' - I think from what you > are saying, that the complex blocks, DLLs etc do not work as low as > the logic fabric, and config SRAMs - so something like an LCD interface, > or a keypad scan could run at < 1MHz at the lower Vccs ? > [ that would allow users to choose between a really small uC, and > some sytem IO in the FPGA, or a larger uC with more pins, and more > agressive power-removals on the FPGA. ] > > > -jg > >Article: 75139
Hi eli,
> I'll give it a try. Thanks !
>
> Eli
Just a few statistics:
Using Quartus II 4.1 SP2, the following code
==== Cut here ====
library ieee;
use ieee.std_logic_1164.all;
entity zort is
port (
clk : in std_logic;
inbus : in std_logic_vector(199 downto 0);
sel : in integer range 0 to 24;
outreg : out std_logic_vector(7 downto 0)
);
end zort;
architecture rtl of zort is
begin
process(clk)
begin
if rising_edge(clk) then
outreg <= inbus(7 downto 0);
for i in 0 to 24 loop
if sel = i then
outreg <= inbus((i*8)+7 downto (i*8));
end if;
end loop;
end if;
end process;
end architecture;
==== Cut here ====
produces 150 LEs when MUX optimization is forced ON, 163 LEs when it's set
to AUTO (lots of room left in the device, so Quartus doesn't bother), but
191 with the default assignment left out. No wonder you're getting worse
timing.
Best regards,
Ben
Article: 75140Hi Andres, Andres Calderon wrote: > Somebody can send an example, document or advice to help me in the > verilog implementation of a OPB module (EDK 6.2) The opb_hwicap core in EDK6.2 is written in Verilog. /path/to/edk/hw/XilinxProcessorLib/pcores/opb_hwicap/... Regards, JohnArticle: 75141
"Prashanth" <prashanth.thota@gmail.com> wrote in message news:be62eac0.0410260832.7f92146b@posting.google.com... > 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, > Prashanth defenetly! using the BSCAN primitive that "routes" to instructions USER1 and USER2 to the FPGA fabric.Article: 75142
Wong wrote:
> Hi,
> Recently I am doing P&R for my FPGA Design. Unfortunately, whenever
> I using the auto P&R provided in the software, I wont find a
> satisfactory result since some internal flip-flops alway have timing
> violations due to the routing, i.e. D-flipflop with setup time
> violation with respect to CLK, etc.
> So I doubt that whether a manual P&R is possible under this
> circumstance. If yes, what are the golden rules to do this manual P&R
> without any tool like floorplanning ? I will assign the gate/cells one
> by one into the FPGA.
Howdy Wong,
Your description is not detailed enough for anyone to give you a
good answer. A copy of *part* of the detailed timing report would go a
long ways towards showing what is wrong (hopefully it shows clock rate
as well as routing and component delays).
Your problem could be caused by any number of issues, from too many
levels of logic to plain old poor placement (either due to the device
being full, too empty, or just bad decisions by the placer), and all the
stuff that goes between. Or maybe it's close and just needs a different
seed.
Good luck,
Marc
Article: 75143Repzak wrote: > > >> 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? I thought that as well. But if you read the text carefully, you will see they are talking about a different kit. The $49 kit is for use with your custom board. They just give you the cable and a 30 license on the software, no board included. -- 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: 75144
eliben@gmail.com wrote:
>
> 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.
You might try writing to Ben Cohen about this since it is in his book.
The title is "HDL Chip Design", the example is in section 7.9
Multiplexer Model, p 202-203. Here is the code example...
library IEEE;
use IEEE.Std_Logic_1164.all;
use IEEE.Std_Logic_Arith.all;
entity Mux is
port (DataIn : in Std_Logic_Vector(17 downto 0);
MuxSelect : in Std_Logic_Vector( 4 downto 0);
MuxOut : out Std_Logic);
end Mux;
architecture Mux_a of Mux is
begin
-- Multiplexer 18 to 1
MuxOut <= DataIn(Conv_Integer(Unsigned(MuxSelect))) when
MuxSelect < "10010" else
'X';
end Mux_a;
I am also suspect of the '<' comparison between the two SLVs. I am not
aware that there is an operator defined for this. But maybe the library
IEEE.Std_Logic_Arith defines this. The absence of this test may be what
caused the error in your case since you could have indexed outside the
array index range. Personally, I would define MuxSelect to be a integer
constrained to the range valid for this case.
You might even contact Ben Cohen directly. He seems to be a pretty good
guy and I expect he would be happy to answer any questions about
possible mistakes in his book. vhdlcohen AT aol D0T com
Let us know what you find.
--
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 FAX
Article: 75145SPARC Based FPGA SoC system I have always being amazed about the "art" of VHDL programming done by Gaisler Research, but the new release of GRLIB for LEON3 is even better. GRLIB includes - LEON3 (Sparc V8) Processor, cache, hardware mul/div, AMBA bus interface - ROM/RAM Controller - PC133 SDRAM Controller - Floating Point unit - AMBA Cores: - Plug and Play AHB controller (peripheral module identify!) - AHB/PHB Bridge (plug and play) - AHB/APB reporting modules - AHB PCI (master/target) - PCI DMA Controller - AHB adapter for opencores ehternet IP - APB UART - APB Timer - APB GPIO - Interrupt Controller additionally are included several simulation cores and models. GLIB is configured using flexible scripting system that supports "hw board support packages" that is the makefile can select what target hw board is used and configures all the toolchain for it. makefiles can be used to start different simulators or generate bitstream using either xilinx or synplify synthesis. There is no GUI builder (aka XPS in EDK) but when the bus modules are simply "wired" together in the toplevel module then all the bus arbitration is done automatically. So creating a customized SoC doesnt take more than few hours. Of course available is full GNU compiler toolchain and scripts to compile example programs. LEON3 can be used for uCLinux and Linux (demo images for both are available). Debug unit allows full access to the AHB bus so it can read write to memory and peripherals. Special DSUMON application can be used to communicate with the debug module. DSUMON is also able to serve as GDB server so GDB debugger can be used as well. Cycle accurate Instruction set simulator is available as well. LEON3 SoC seems to use a bit more FPGA resources then as example MicroBlaze based system, I did an example SoC (with about the amount of peripherals) MicroBlaze Soc: 1700 Slices Sparc SoC: 3500 Slices What I would like to know is how much would the Sparc SoC decrease in resources if resynthesised using Synplicity Amplify, my bet is that it would come down to approx 2400 Slices from 3500 But even so, with XST synthesis its obvious that Sparc based SoC is already heavy competion to vendor SoC systems, specially when targetting the latest FPGA families and larger chips. In XC2V1000 the Small Sparc SoC takes around 50% (XST synthesis) what is relativly heavy price, but in larger family member and in case the peripheral IPs are large the actual percentage consumed by Sparc CPU comes smaller. Of course I could imagine that its not so complicated to develop a Sparc-Lite version that could compete with resource useage with vendor CPU solutions. Why I wrote this? Because I think that LEON3/GRLIB has had too few exposure, and well I always liked SPARC - it my personal favorite ISA. Once upon a time I wanted to obtain Sparc CPU chips made by Plessey, I had some idea for an commercial product - I never got them, by my idea still lives one, and now I can have the Sparc in low cost FPGA, thats great! Antti LukatsArticle: 75146
Steve Lass wrote: > > Not really. It was a conscious decision to avoid having to provide 2 > different service packs. > > Steve > > Gavin Scott wrote: > > >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? :-) Ok, I am still confused about this. Does the current 6.3 webpack, service pack 2 include the 3S2000/4000 or not? Is it in now and will be taken out in 7.1? Oh, I think I understand now. The two different service packs are for the webpack and the ISE, right? So the current webpack *does* include all the spartan 3 devices, but will not in the future. Ok, I understand. -- 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: 75147
I probably am misleading some what... but experience for a typical design is FPGA's don't consume much. they are usually the lowest power consumer on my designs. but done right.... An FPGA will draw less power than a micro doing the same thing. the last card had a dynamic current in the FPGA of about 8 mA (excluding I/O) that's according the power calculator and the interface it connected to could draw 2amps. I don't think that's too bad. And I usually do design to the spec... we rate our radios from -10C to +65C and aren't allowed more than 2 'noise' hits over a temperature cycle. But for a piece of test gear sitting on a bench.. I think you can go slightly wild and limit the temperature range... unless you going to sit it in a shed in a desert... which I doubt. I saw your battery... not bad... but usually higher voltages win out over higher amp-hour... at low voltages the switcher losses become silicon volt drop related. If you look at Maxium you will see they quite often invert the voltage and then switch up from the sum of the voltages to get the efficiency up when working with low voltages. Am glad you like the Q FPGA. I came across it while helping design a satellite here. Its fuse link, no free tools, no free programmer... so I would defiantly prototype with something else until you can be assured of it working. For driving a FPGA from a CPLD.. you might need an interface IC in between. There are a number of logic families that support hot-swap which should stop any current draw when the chip is in power down.. failing that.. 10k resisters are pretty good too :-) Or you could make sure all devices drive the FPGA with a low by default... then there is no power for the protection diodes to suck :-) Simon "Symon" <symon_brewer@hotmail.com> wrote in message news:2u7hb2F25pfq8U1@uni-berlin.de... > 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/ > >Article: 75148
"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message news:qh3c01co68.fsf@ruckus.brouhaha.com... > "David Brown" <david@no.westcontrol.spam.com> writes: > > The x86 architecture is propritery, > > or "closed" - you need a license to be able to make an implementation. > > Since when? > > Are you asserting that the IIT, Nexgen, Rise, and Transmeta x86 designs > were licensed by Intel? I don't know the details, nor how much needs licenses, but I believe AMD and Intel have cross-licensing deals on their x86 architectures. I also remember hearing about Intel suing companies for making one type of x86 chip when they only had a license for a different generation of x86 designs. At least some of the licenses Intel has provided have not been by choice, but by court order. However, it could be that all this refers to something other than the x86 architecture itself (maybe something to do with the implementation, or arrangements of special registers, or whatever), and the x86 is not proprietry. In that case, pick a different example, like ARM.Article: 75149
Hi, Anyone know what is Xilinx recommended pull-up resistor value for Virtex-4 configuration pins (TCK, TDO, TDI, TMS and M0-M2)? Thanks, Ivan
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