Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hi,
Older generation FPGA familes such as XC4000/5000 Spartan/XL have PC84
package but Webpack dosen't support those families.
If you are stuck on using those, you need a synthesis tool from synplicity
or mentor and use the ise classic for the design.
But new families like Spartan2/2E/3 with QFP packages would be a better bet.
Sandeep
"Jon Elson" <jmelson@artsci.wustl.edu> wrote in message
news:41C7375D.4080308@artsci.wustl.edu...
>
>
> Vadim Vaynerman wrote:
>
> >Sorry about that, I missclicked...
> >
> >My question is this: is there ANY Xilinx FPGA that comes in a PLCC84 or
PC84 package that is supported by the WebPck tools? I couldn't find that
package for Spartan II devices, only for CPLDs, and I really want to use an
FPGA. Any Ideas?
> >
> >
> I use the 5V XCS10PC84C. I don't know if webpack supports it. I use an
> old version
> of the Xilinx iSE tools which has support for the 5 V devices. The
> older Foundation
> software also supported these.
>
> Jon
>
Article: 77051Hello, To keep it simple you can try using a dual port ram. Xilinx advantage true dual port ram. Sandeep "Tommy Thorn" <foobar@nowhere.void> wrote in message news:uj8yd.13718$_3.154971@typhoon.sonic.net... > JTW wrote: > > If I have two or more sections of logic in my FPGA that need to read and write > > to the same memory, what is the typical/standard approach to control who > > writes/reads when? Is there an example somewhere that I > > could look at? > > Thanks, JTW > > It's a problem more general than just memory, ie. you could be sharing > other devices. For the most general case you need some kind of > interconnect structure and arbitration, like for example Avalon (offered > by Altera) or WISHBONE (notably used by OpenCores, though I couldn't > seem find a bus arbiter). > > Often however, you can use system specific knowledge to adopt a simpler > solution, such as running the memory at twice the speed, using odd > cycles for one device, and even for the other (rarely works for external > memory though). > > TommyArticle: 77052
Shreyas, Go through the book PCI SYSTEM ARCHITECTURE by TOM SHANLEY / DON ANDERSON Very good book....you will understand the whole PCI architecture. Regards PraveenArticle: 77053
Hello Kiran,
You might take a look at app. note Xapp502 to get clues
on how you can do this.
The commands to load data into registers is embedded in the bit
file, the interface is straight forward.
Two things I would like to mention are:
1. Use bin file instead of bit file
2. Take caution on bit swapping.
Regards
Sandeep Kulkarni
"Kiran M" <kiran@fepis.com> wrote in message
news:1103385687.64ba849840fe6197fd9af706a6e98bcc@teranews...
> Hi everybody,
> I want to program a embedded microcontoller to load a
> configuration bitstream using the slave select MAP mode of virtex II.
> Are there any command words to be issued to commence programming or
> just read the bitstream byte by byte and write it into the select MAP
> data pins.
Article: 77054Austin Lesea wrote: > eliben, > > I was waiting for all responses to trickle in before wading in. > > Why would any technology be less reliable? > > Are you concerned about the robustness of the technology to overvoltages? > > If this is the case, this is beyond the issue of reliability, it is an > issue of not liking the absolute maximum ratings, which have gotten > lower as the technolgy shrinks. > > Again, this has nothing to do with reliability. In my experience, questions like this refer to operational reliability, not device MTBF. So to answer the question in this context : Yes, a lower voltage device has lower voltage margin, so it is less tolerant of the same ground noise. Even worse, from an industrial context, 90nm devices are faster, so they can 'see' a spike older devices simply miss. Some semiconductor vendors graph pulse width / pulse amplitude for disturbance limits, but I have not seen this for FPGA. Thus an industrial user is right to be cautious, and should include field tests in the design. Arcing contacts : Relays, Motor brushes, contactors etc can easily generate sub-ns wavefronts at hundreds of volts. You can run a spice simulation, to see how much coupling C is needed, to generate (say) a 1V bounce in 10nH of trace inductance. A good practical noise generator is a relay that self-commutates, and switches mains. Or Piezo gas lighters... -jgArticle: 77055
Neil, Try this http://www.fpga-faq.com/archives/59400.html#59400 Cheers, Syms. "Neil" <logblog@gmail.com> wrote in message news:1103583946.091639.312550@c13g2000cwb.googlegroups.com... > > Not PLL, I am looking at various types of synchronization techniques > for signals crossing clock boundaries. > > - Neil >Article: 77056
Hi Glen, I'm being dense; why would it leave glitches through the routing? Once you cascade LUTs without the FFs it could, but the FF fed LUT's output, and hence the routing it subsequently feeds, should be glitch free. What am I missing? Cheers, Syms. "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:cq82s3$6n3$1@gnus01.u.washington.edu... > > You mean put four FF's on the LUT inputs, instead of one on the > output? I suppose that reduces glitching inside the LUT (RAM), > but it still leaves glitches through the routing. Also, four > FF's are likely to take more power than one. > > -- glen >Article: 77057
Hi Tim, Thanks for the heads up. Googleing Mr. Trimberger's name, I found this EE times article:- http://www.eet.com/semi/news/showArticle.jhtml?articleId=9900516&kc=2515 quote> Xilinx has already taken the first steps to raise the awareness of power issues by disclosing a study on the hot spots in its latest Virtex 2 architecture. In the paper, the company showed that 60 percent of the power consumption in the Virtex 2 family is from routing while logic and clocking account for 16 and 14 percent, respectively. Additionally, Xilinx found that the cluster of LUTs, flip-flops and other circuitry that make up its configurable-logic blocks take up 5.9 microwatts per MHz for a typical design. But this is just for "typical" designs; actual power consumption within the configurable logic blocks (CLBs) can change wildly depending on the switching activity. This can occur frequently in synchronous circuits, where the inputs to the LUTs come in at different times during the same clock cycle. This "glitching" effect could contribute up to 70 percent of the power dissipation in a CMOS circuit, whether it's an ASIC or FPGA. <quote Cheers, Syms. "Tim" <tim@rockylogic.com.nooospam.com> wrote in message news:cq80ut$681$1$830fa79f@news.demon.co.uk... > As I understand it (!) Stephen Trimberger (Xilinx and much > distinguished previous work) presented a paper recently on > this fairly recently. > > "Symon" <symon_brewer@hotmail.com> wrote in message > news:31qgosF3cc0s9U1@individual.net... >> Hmm, that's very interesting. I wonder if the FPGA vendors have got their >> SLICEs back to front? I.e. the FFs should feed directly into the LUTs >> within the SLICEs, instead of the other way round that exists now. If it >> saved even 20% of the power, it'd be worth it. Instead of using all the >> FFs for pipelining, you use them to replicate signals within the SLICEs >> to prevent the glitchy power thing. Hmm, interesting indeed! Thanks Ray. >> Cheers, Syms. > >Article: 77058
I am trying to use the chipscope pro version 6.3 (tried also 6.2 but results were the same). While mapping the design, I get the following error messages: **************************************************** START HERE **************************************************** ... Phase 1.1 The following components are involved in this logic: SLICE i_ila/ila/i_no_d/u_ila/u_trig/u_tm/g_nmu/1/u_m/u_mu/i_mut_gand/u_match/pd_rpm/i_ tw_gte8/f_tw/3/i_yes_rpm/u_muxh/O SLICE i_ila/ila/i_no_d/u_ila/u_trig/u_tm/g_nmu/1/u_m/u_mu/i_mut_gand/u_match/pd_rpm/i_ tw_gte8/f_tw/2/i_yes_rpm/u_muxh/O SLICE i_ila/ila/i_no_d/u_ila/u_trig/u_tm/g_nmu/1/u_m/u_mu/i_mut_gand/u_match/pd_rpm/i_ tw_gte8/f_tw/1/i_yes_rpm/u_muxh/O SLICE i_ila/ila/i_no_d/u_ila/u_trig/u_tm/g_nmu/1/u_m/u_mu/i_mut_gand/u_match/pd_rpm/i_ tw_gte8/f_tw/0/i_yes_rpm/u_muxh/O This situation can be resolved by fixing the following issue: The structured logic could not be placed in the relative placement form required. This is due to the fact that the component i_ila/ila/i_no_d/u_ila/u_trig/u_tm/g_nmu/1/u_m/u_mu/i_mut_gand/u_match/pd_rpm/i_ tw_gte8/f_tw/1/i_yes_rpm/u_muxh/O is already contained in an rpm that will not allow the logic to be placed in the legal form. The following components are involved in this logic: SLICE i_ila/ila/i_no_d/u_ila/u_trig/u_tm/g_nmu/1/u_m/u_mu/i_mut_gand/u_match/pd_rpm/i_ tw_gte8/f_tw/3/i_yes_rpm/u_muxh/O SLICE i_ila/ila/i_no_d/u_ila/u_trig/u_tm/g_nmu/1/u_m/u_mu/i_mut_gand/u_match/pd_rpm/i_ tw_gte8/f_tw/2/i_yes_rpm/u_muxh/O SLICE i_ila/ila/i_no_d/u_ila/u_trig/u_tm/g_nmu/1/u_m/u_mu/i_mut_gand/u_match/pd_rpm/i_ tw_gte8/f_tw/1/i_yes_rpm/u_muxh/O This situation can be resolved by fixing the following issue: The structured logic could not be placed in the relative placement form required. This is due to the fact that the component i_ila/ila/i_no_d/u_ila/u_trig/u_tm/g_nmu/1/u_m/u_mu/i_mut_gand/u_match/pd_rpm/i_ tw_gte8/f_tw/1/i_yes_rpm/u_muxh/O is already contained in an rpm that will not allow the logic to be placed in the legal form. Phase 1.1 (Checksum:a293af) REAL time: 39 secs Phase 2.2 Pl_Group:: Id=3273 numComps=3 locked=FALSE active=FALSE level=0 clientId=0 Comp = fifo_over_under_flow type = LUT numpins = 14 Comp = fifo_over_under_flow type = LUT numpins = 0 Comp = fifo_over_under_flow type = FF numpins = 0 ..................................... ERROR:Place:379 - Unable to place the following group for unknown reason LUT i_ila/i_no_d/u_ila/idata_24 (0, 0) FF i_ila/i_no_d/u_ila/idata_24 (0, 1) ERROR:Place:379 - Unable to place the following group for unknown reason LUT i_ila/i_no_d/u_ila/u_g2_sq/u_capctrl/u_cap_addrgen/cfg_data_4 (0, 0) FF i_ila/i_no_d/u_ila/u_g2_sq/u_capctrl/u_cap_addrgen/cfg_data_4 (0, 1) ERROR:Place:120 - There were not enough sites to place all selected components Phase 2.2 (Checksum:1312cfe) REAL time: 1 mins 39 secs ERROR:Pack:1499 - The timing-driven packing phase encountered an error. Mapping completed. See MAP report file "gtw_map.mrp" for details. Problem encountered during the packing phase. Design Summary -------------- Number of errors : 4 Number of warnings : 10 Time spent in user mode (CPU seconds) : 198.870s Time spent in kernel mode (CPU seconds) : 1.970s Total time : 3:21.43s CPU utilisation (percentage) : 99.7% Times the process was swapped : 0 Times of major page faults : 6800 Times of minor page faults : 233235 **************************************************** END HERE **************************************************** After which the mapper failes. If I remove the "-timing" option of the MAP, the mapper succeeds but the PAR failes (unrouted signals). Any suggestions ? RanArticle: 77059
What is the error message. What is your directory structure in your working file. Where did you place the netlist?Article: 77060
I have read the literature on the the Xilinx DSOCM IF Controller but have a question. Does this piece of IP need to be connected to the DCR Bus in order to get at the DCR registers - currently in my EDK graphic I only have it attached to the BRAM it controls and straight into the PPC. If not how do I access the DCR regs for this IP - I have tried mfdcr and mtdcr before from within my software but cannnot compile as there appears to be no ".obj" for them. AM I being daft ?Article: 77061
Gary, As I said in my post, if one follows the foundry rules, there is no reason why 90nm should not last at least as long as any earlier technology. Heat is the enemy for all silicon devices, so keeping power dissipation down is always a good thing. That is why we are quite happy with the advantages we gained from the triple oxide technology in V4: half to 1/3 the leakage of other large 90nm FPGAs, 40% the dynamic power of the 130 nm Xilinx V2 Pro (fabric), and no start up surges. Austin Gary Pace wrote: > I use a Cyclone on a gate drive for a high power IGBT - a VERY noisy > environment. The precautions I took were : > > - Convert I/O to/from 5v directly adjacent to the device. The higher voltage > signals then proceed around the PCB > - Around the FPGA itself, create multiple ground/power planes - including > one on an external layer to serve as a shield > - Make provision for additional shielding (i.e. copper planes mounted above > the FPGA sub-system) - didn't use this in the end. > - Use an accurate linear reg. and set the internal voltage at the upper end > of the tolerance > > I don't know which of these were important, but the device has performed > like a champ > > I do have a concern concerning longevity (often much more important in > industrial stuff than commercial). This is to do with the stability of the > sub-micron geometries used in devices such as this. To alleviate these > concerns, I make sure it runs really cool. I don't know if anyone else can > comment on this concern. > > Gary > > <eliben@gmail.com> wrote in message > news:1103526760.055590.264630@z14g2000cwz.googlegroups.com... > >>Hello, >> >>We're employing FPGAs in industrial conditions >>(wide temperature range, noise). Currently we >>are using ACEX1K. Some people are reluctant to >>move to the new technologies (Stratix, Stratix II) >>because of their low core voltage. >> >>Are there are articles about the reliability of >>various FPGAs in industrial applications ? Any >>information about the lower reliability of 1.8 >>and 1.5 volt core devices ? >> >>Tx >> > > >Article: 77062
You can connect the on port of the BRAM to the DSOCM interface of the ppc. That enables you to direcly read and write to the BRAM on one port. On the other port you can connect the BRAM to any other stuff µC or VHDL-process. I did not use the DCR registers. What do you plan to do with them?Article: 77063
Kiran - There are no magic tricks to using the select map mode. I've used it several times to allow downloading of byte-wide data via a parallel port though some level shifters into the FPGA. The things to be aware of are: a) make sure you have the 3 mode pins strapped properly. b) make sure you have the CS/ and RDWR pins properly set. c) you need to assert PGM/ pin to start and wait for INIT/ to be released before sending data. d) be careful about voltage levels - some signals can't be 3.3V without some conditioning. I've found notes on the web on the format of .bit files, so my s/w uses those data files to download to the FPGA. NOTE you can't just send the .bit file to the FPGA, there is header info that needs to be stripped off. Be aware of bit ordering, each file format seems to treat MSB or LSB first differently. John Providenza Sandeep Kulkarni wrote: > Hello Kiran, > You might take a look at app. note Xapp502 to get clues > on how you can do this. > The commands to load data into registers is embedded in the bit > file, the interface is straight forward. > Two things I would like to mention are: > 1. Use bin file instead of bit file > 2. Take caution on bit swapping. > > Regards > Sandeep Kulkarni > "Kiran M" <kiran@fepis.com> wrote in message > news:1103385687.64ba849840fe6197fd9af706a6e98bcc@teranews... > > Hi everybody, > > I want to program a embedded microcontoller to load a > > configuration bitstream using the slave select MAP mode of virtex II. > > Are there any command words to be issued to commence programming or > > just read the bitstream byte by byte and write it into the select MAP > > data pins.Article: 77064
Hi, group, I am looking for one piece of low cost alterma MAX II (EPM1270) development kit. What I need is basically the chip mounted on a small board with JTAG pins and almost all I/O pins available. The $150 Altera kit provides only some 40+ I/O pins, with many features that I don't need. Does such a kit exist? I'd expect lower cost than $150. $80(with shipping) is OK, $50 is prefered. If you know of this product, please let me know. Thanks. vax, 9000Article: 77065
Look at the TechXclusives article "Moving Data Across Asynchronous Clock Boundaries" Click at http://support.xilinx.com/xlnx/xweb/xil_tx_home.jsp and scroll down to 7-10-2001 Peter AlfkeArticle: 77066
Jim Granville wrote: > Austin Lesea wrote: > >> eliben, >> >> I was waiting for all responses to trickle in before wading in. >> >> Why would any technology be less reliable? >> >> Are you concerned about the robustness of the technology to overvoltages? >> >> If this is the case, this is beyond the issue of reliability, it is an >> issue of not liking the absolute maximum ratings, which have gotten >> lower as the technolgy shrinks. >> >> Again, this has nothing to do with reliability. > > > In my experience, questions like this refer to operational reliability, > not device MTBF. > > So to answer the question in this context : Yes, a lower voltage device > has lower voltage margin, so it is less tolerant of the same ground noise. > Even worse, from an industrial context, 90nm devices are faster, > so they can 'see' a spike older devices simply miss. > > Some semiconductor vendors graph pulse width / pulse amplitude > for disturbance limits, but I have not seen this for FPGA. > > Thus an industrial user is right to be cautious, and should include > field tests in the design. > > Arcing contacts : Relays, Motor brushes, contactors etc can easily > generate sub-ns wavefronts at hundreds of volts. > > You can run a spice simulation, to see how much coupling C is needed, > to generate (say) a 1V bounce in 10nH of trace inductance. > A good practical noise generator is a relay that self-commutates, and > switches mains. Or Piezo gas lighters... > > -jg > > I always wondered about the volatile configuration memory getting corrupted. Any comments on that issue?Article: 77067
If I have two or more sections of logic in my FPGA that need to read and write to the same memory, what is the typical/standard approach to control who writes/reads when? Is there an example somewhere that I could look at? Thanks, JTWArticle: 77068
David, This issue is at least as old as the static configuration latches that are used to hold the configuration: what will cause config bits to change? In order to make FPGAs work (at all), one has to start with a very robust memory cell design. NOT SRAM! We use specially engineered (for the myriad of requirements we have) cross coupled CMOS latches. They can be slow. They can be heavily loaded (the more loads the better). They must run at the highest internal voltage we have to be used to control the pass gates (also good for stability). They must be immune to read disturb (as we can readback while operating). They must be easy to write. They must be very low leakage. They must meet our SEU (soft error upset) reliability criteria. If the power supply itself glitches, the POR (power on reset) circuit uses dummy memory cells to detect if they can be upset (selected sizes of loads to mimic the most sensitive memory cell). So, if there is enough of a power supply glitch to flip a memory cell used for configuration, the POR will trip, and the device will reconfigure (as it lost it memory from the glitch). How else can you flip those bits? 1) Place in nuclear reactor 2) Inject massive amounts of current into the substrate by excessive undershoot (as in many many amperes from a bunch of IOs switching at once -- exceeds the Latch up spec, but no latch up will occur, just de-programming) 3) exceeding the absolute maximum specifications in other ways we haven't dreamed of (yet) AustinArticle: 77069
I wrote: >>You mean put four FF's on the LUT inputs, instead of one on the >>output? I suppose that reduces glitching inside the LUT (RAM), >>but it still leaves glitches through the routing. Also, four >>FF's are likely to take more power than one. Symon wrote: > I'm being dense; why would it leave glitches through the routing? Once you > cascade LUTs without the FFs it could, but the FF fed LUT's output, and > hence the routing it subsequently feeds, should be glitch free. What am I > missing? I didn't try to figure all possibilities, but it would be a rare design that used a FF on each LUT output, so I would expect some LUT without FF's on the inputs. The arrival time will be different for the different inputs, so there may (depending on logic) still be glitches left. I do agree, though, that for many designs it could greately reduce glitches propagating through logic. I have done designs with at most two LUT between FF's, highly pipelined for high speed. I do agree that it could be an interesting addition to FPGA architecture, and you might want to patent it. (If you do, it will probably never get into any FPGA's though.) -- glenArticle: 77070
Hi Brad,
There is a FIFO overflow, I think. Let me explain wht I think I see:
When valid frame data is available (vframe_2 = '1'), you start saving data
on the rising edge of the line indicator (vline1 = '1' AND vline_2 = '0').
Once the second line starts, you start reading out the FIFO. If a frame has
H lines, you will have stored H lines, but only read out (H - 1)!
[ASCII graph, use fixed font]
______________________ ______________________
FRAME ___/ \___/ \___
__ __ __ __ __ __
LINE ______/ \___/ \___/ \_________/ \___/ \___/ \______
___________________ ___________________
WRITE ______/ \______/ \___
____________ ____________
READ _____________/ \_____________/ \___
The fix is to start reading out the FIFO at the same time as you start
writing it, except for the very first line that you store (because you have
to fill the FIFO with 1 line of data). You can use the same starting
condition, except that you have to check the FIFO for not being empty before
launching the reads. There are 2 possibilities to do this:
1) check the FIFO's empty flag
2) have a register that is reset along with the other registers and only set
by the write enable (less resources if the FIFO hasn't the empty flag by
default).
My next comment is on the robustness of your design: what happens when you
switch on the video source or when you reset your design while the source is
running? There is no reason you will start saving the data from the first
line in a frame: if you see the 3th line pulse in a frame first after reset,
the you will currently start storing there. The solution is to have an
additional enable register that is reset like the others and is set when
frame is low: as such, no line will be stored before you have seen frame
going low.
Combining my remarks should give you the following waves:
[ASCII graph, use fixed font]
___
RESET
\_____________________________________________________________________
_______________ ______________________ ______________________
FRAME \___/ \___/
\___
__ __ __ __ __ __ __ __
LINE __/ \___/ \_________/ \___/ \___/ \_________/ \___/ \___/
\______
________________________________________________________
FRMen+ ________________/
___________________ ___________________
WRITE ______________________/ \______/
\___
_________________________________________________
nEMPT+ _______________________/
____________ ___________________
READ _____________________________/ \______/
\___
Summarised:
WRITE start at the first line of a frame
READ start at the first line of a frame that the FIFO is not empty
If you're still up to some comments: the delay of the signal driving the mux
of vin_3 and the "10101010" constant puzzles me: assuming 1 cycle delay
between fiforden and the data coming out of the FIFO, then vin_3 and
fifodout are nicely aligned. But you add 2 more delays in process v5 by
using video_bits_2. Is this what you need (you're shifting the decision 2
pixels)?
Likewise, when you're checking for the treshold of the lines (current - 2)
and (current - 3), did you consider the wrapping from the bottom line to top
line in the next frame?
Some very last suggestion: do you check the timing of your asynchronous
reset? Without a flipflop clocking this signal, you will have no control
over it and you risk all kind of trouble (meta-stability when violating
setup/recovery timing of the resetable flipflops, flipflops coming out of
reset in a different clock cycle). In an FPGA, it's safer to use a
synchronous reset and it won't cost you any more resources (see the FPGA
registers).
Kind regards,
Alvin.
Article: 77071David Colson wrote: > Jim Granville wrote: > >> Austin Lesea wrote: >> >>> eliben, >>> >>> I was waiting for all responses to trickle in before wading in. >>> >>> Why would any technology be less reliable? >>> >>> Are you concerned about the robustness of the technology to >>> overvoltages? >>> >>> If this is the case, this is beyond the issue of reliability, it is >>> an issue of not liking the absolute maximum ratings, which have >>> gotten lower as the technolgy shrinks. >>> >>> Again, this has nothing to do with reliability. >> >> >> >> In my experience, questions like this refer to operational reliability, >> not device MTBF. >> >> So to answer the question in this context : Yes, a lower voltage device >> has lower voltage margin, so it is less tolerant of the same ground >> noise. >> Even worse, from an industrial context, 90nm devices are faster, >> so they can 'see' a spike older devices simply miss. >> >> Some semiconductor vendors graph pulse width / pulse amplitude >> for disturbance limits, but I have not seen this for FPGA. >> >> Thus an industrial user is right to be cautious, and should include >> field tests in the design. >> >> Arcing contacts : Relays, Motor brushes, contactors etc can easily >> generate sub-ns wavefronts at hundreds of volts. >> >> You can run a spice simulation, to see how much coupling C is needed, >> to generate (say) a 1V bounce in 10nH of trace inductance. >> A good practical noise generator is a relay that self-commutates, >> and switches mains. Or Piezo gas lighters... >> >> -jg >> >> > I always wondered about the volatile configuration memory getting > corrupted. Any comments on that issue? There have been other threads on that. The config RAM is slower, and more immune to radiation upset, than the smaller/nimble logic. But it can still happen, so the mission critical systems usually have the ability to re-config. -jgArticle: 77072
"vax, 9000" <vax9000@gmail.com> wrote in message news:cq9kds$334$1@charm.magnus.acs.ohio-state.edu... > Hi, group, > I am looking for one piece of low cost alterma MAX II (EPM1270) > development kit. What I need is basically the chip mounted on a small > board > with JTAG pins and almost all I/O pins available. The $150 Altera kit > provides only some 40+ I/O pins, with many features that I don't need. > Does > such a kit exist? I'd expect lower cost than $150. $80(with shipping) is > OK, $50 is prefered. If you know of this product, please let me know. I'll design and make you one for $80, if you can supply me with a couple of the chips (one for me and one for you). They are only available by the tray (90 pcs), AFAIK. LeonArticle: 77073
Austin Lesea <austin@xilinx.com> writes: > That is why we are quite happy with the advantages we gained from the > triple oxide technology in V4: half to 1/3 the leakage of other large > 90nm FPGAs, The "other large 90mm FPGAs" being Spartan 3? > and no start up surges. I thought Spartan 3 already had that? If so, how is it a feature of "triple oxide technology"?Article: 77074
Austin Lesea wrote: > David, > > This issue is at least as old as the static configuration latches that > are used to hold the configuration: > > what will cause config bits to change? > > In order to make FPGAs work (at all), one has to start with a very > robust memory cell design. NOT SRAM! > > We use specially engineered (for the myriad of requirements we have) > cross coupled CMOS latches. > > They can be slow. > > They can be heavily loaded (the more loads the better). > > They must run at the highest internal voltage we have to be used to > control the pass gates (also good for stability). > > They must be immune to read disturb (as we can readback while operating). > > They must be easy to write. > > They must be very low leakage. > > They must meet our SEU (soft error upset) reliability criteria. > > If the power supply itself glitches, the POR (power on reset) circuit > uses dummy memory cells to detect if they can be upset (selected sizes > of loads to mimic the most sensitive memory cell). So, if there is > enough of a power supply glitch to flip a memory cell used for > configuration, the POR will trip, and the device will reconfigure (as it > lost it memory from the glitch). > > How else can you flip those bits? > > 1) Place in nuclear reactor > 2) Inject massive amounts of current into the substrate by excessive > undershoot (as in many many amperes from a bunch of IOs switching at > once -- exceeds the Latch up spec, but no latch up will occur, just > de-programming) > 3) exceeding the absolute maximum specifications in other ways we > haven't dreamed of (yet) > > Austin Thanks for the info. Now I fell better. We are using Spartan II, IIe and IIIs in out brusless motor drives. Which have large voltage and current swings up to 340 volts and 18 amps, and only inches away form the FPGA! Dave Colson
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