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
With all due respect, I have a different explanation of hold time. It is
based on the mismatch between data and clock delay in the master latch:
If the data delay is longer than the clock delay, there is a set-up
time, but no hold time ( negative hold time)
If the clock delay is longer than the data delay, there is a hold time
requirement, but no set-up time.
The difference between data and clock delay moves the data capture
window. For a given circuit, temperature and voltage, this window is
extremely small ( see the metastability tests, which demonstrate a
sub-femtosecond window).
For reliable operation, the manufacturer specifies a worst-case window
of set-up + hold time.
All smart chip manufacturers try to err on the side of zero or negative
hold time, and accept the corresponding larger set-up time.
An unduely large set-up time sacrifices max clock rate.
A positive hold time can mean unreliable operation at any speed. :-(
Peter Alfke
Andrew Paule wrote:
>
> Hold time is a quantum statistical thing - thermal trip of a balanced
> pair. Been through this in this newgroup before.
>
> Andrew
>
> Glen Herrmannsfeldt wrote:
>
> >"Tom Derham" <tderham@NOSPAM.ee.ucl.ac.uk> wrote in message
> >news:bkn1gm$d00$1@uns-a.ucl.ac.uk...
> >
> >
> >>I am using one counter to trigger a second counter.
> >>The first counter is loadable but typically runs for a long time ('count'
> >>
> >>
> >is
> >
> >
> >>28 bit).
> >>This counter keeps running, and each time it terminates, produces a pulse.
> >>This pulse is used to trigger the second counter, which typically runs for
> >>much less time ('count' is 8 bit). This counter produces output 1 while
> >>
> >>
> >it
> >
> >
> >>is counting, then returns to 0 until it is retriggered by the pulse from
> >>
> >>
> >the
> >
> >
> >>first counter.
> >>The whole design is synchronous (running of a single clock at 100 MHz),
> >>using Webpack on Spartan IIE.
> >>
> >>Question: how long must the pulse from the first clock be, to ensure that
> >>
> >>
> >it
> >
> >
> >>triggers the second clock? As I see it, if it is one clock cycle long,
> >>
> >>
> >then
> >
> >
> >>the second clock should trigger on the next clock rising edge (providing
> >>
> >>
> >the
> >
> >
> >>sum of clock propagation and the 2nd clock flip-flop setup is less than
> >>
> >>
> >one
> >
> >
> >>clock cycle)... but functionally the pulse will fall back at the moment it
> >>is triggered (one cycle later), so will only work if the hold time of the
> >>flip-flop is less than the clock propagation.
> >>Is this safe? Does the pulse need to be longer? Will the simulation
> >>
> >>
> >tools
> >
> >
> >>realise if there is a problem here?
> >>
> >>
> >
> >The problem should be exactly the same as that in building the synchronous
> >counter in the first place.
> >
> >I still remember from many years ago, that the 74LS74 has 0 hold time, but
> >the 7474 has a positive hold time. You can make T flip-flops by connecting
> >Qbar to D on a 74LS74, but not (reliably) on a 7474. Most likely even one
> >level of logic in between would be enough, though.
> >
> >The LSB of a synchronous counter would normally have the shortest feedback
> >path. That would be the first place to look.
> >
> >As I understand it, FPGA's are usually designed so that in a synchronous
> >design you don't have to worry about hold time, though possibly setup time.
> >It might be that it is not possible to make a feedback path short enough,
> >even if the FF itself has a positive hold time.
> >
> >Now, some people might design a synchronous counter with a clock input from
> >the TC pulse of another synchronous counter. That would not qualify as
> >synchronous logic, and could cause timing problems.
> >
> >-- glen
> >
> >
> >
> >
> >
> >
Article: 60801On Mon, 22 Sep 2003 21:54:16 +0000, Julien Eyries <NOeyries.SPAMjulien@wanadooPLEASE.fr> wrote: >Hello all, > > I have one question about usage of LUT and Registers in Xilinx >Virtex 2 FPGA: > > if, inside a slice, the LUT is consumed by some logic product, but >not the corresponding register, is this register available for other use >(for example, registering signal coming from an other slice) ? or is it >disabled for the whole design ? does it depend on the compilation tool ? It is available for other purposes. Look at the picture of the internals of a slice in the V2 data sheet. If you are using less than 99% of the slices in the FPGA, map (which is responsible for assigning logic to slices) will not put unrelated LUTs and FFs into the same slice. (See the map report for the amount of "unrelated logic packing".) This explains why you can keep adding logic to your design, but the slice utilisation stays at 99%. Map tries to avoid unrelated logic packing because this tends to make the later placement pass much more difficult. Does this waste slices? Sure, but what else are you going to do with them? Regards, Allan.Article: 60802
"Peter Alfke" <peter@xilinx.com> wrote in message news:3F6F949F.E7846BD0@xilinx.com... > With all due respect, I have a different explanation of hold time. It is > based on the mismatch between data and clock delay in the master latch: > If the data delay is longer than the clock delay, there is a set-up > time, but no hold time ( negative hold time) > If the clock delay is longer than the data delay, there is a hold time > requirement, but no set-up time. > > The difference between data and clock delay moves the data capture > window. For a given circuit, temperature and voltage, this window is > extremely small ( see the metastability tests, which demonstrate a > sub-femtosecond window). > For reliable operation, the manufacturer specifies a worst-case window > of set-up + hold time. > All smart chip manufacturers try to err on the side of zero or negative > hold time, and accept the corresponding larger set-up time. > An unduely large set-up time sacrifices max clock rate. > A positive hold time can mean unreliable operation at any speed. :-( I don't know that it was every explained why, but there have been descriptions of the Cray-1 that included PC board traces taking extra long paths, like zig-zags, to lengthen the propagation time. It may have been to match hold time. -- glenArticle: 60803
"Peter Alfke" <peter@xilinx.com> wrote in message news:3F6F9240.E1B74AB5@xilinx.com... > Here are some practical points. > For all but the most extremely fast applications ( say up to 200 MHz), > synchronous counters are built using a global clock, and the bult-in > free ripple carry structure, which of course determines a max frequency > (where the ripple carry can still meet the set-up time requirements of > the MSB.) Decoding TC can be quite tricky, that's why I suggested the > digital differentiator which actually detects TC+1. Maybe I misunderstood the application. I had thought it was a divide by N counter, where at some count value the counter is reloaded with the initial value, and at the same time the second counter is started. Now that I think about it, you should get the carry out from the MSB when the counter is about to wrap. That would seem easier than detecting other values, and can be used as the load input for both. -- glenArticle: 60804
Hi Austin,
Agreed, the simulation is best way! My fag-packet calculation
was a worst case scenario, but still didn't exceed the specification.
Just wanted to confirm to myself there's no problem at the driver end,
and that this talk of using 3V VCCO instead of 3.3V was not needed to
be heeded! (At least for driver pin reasons.)
I imagine your simulation gets a lower value for the reflection
amplitude because the IBIS model includes rise time information and
chip capacitance, rather than variation of the transistors' impedance.
(But I'm willing to be shot down in flames!!) My calculation assumed
instant (worst case) rise time. How long was your lossless t-line? Was
the flight time longer than the rise time of the signal? (Time for
signal travel is about 180ps/in, typically.)
So, thanks for doing the simulation, I don't suppose you'd
publish the results just to put this one to bed for good?
cheers, Syms
Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F6F5B7D.7059DDE5@xilinx.com>...
> Symon,
>
> As if often the case, if you do not run a simulation, you will not get results that are
> even close to the truth (by guessing at what is happening).
>
> With a driver impedance of 8.8 ohms (from IBIS simulation), the overshoot/undershoot back
> at the driver is less than 100 mV (no pcb or t-line losses, IBIS done with Hyperlynx).
>
> Why does this not scale exactly as you state? Because the ON resistance of the
> transistors is not very linear, and they are less than 8.8 ohms near Vcc or ground.
>
> So, unless you simulate the actual circuit, you will not get the actual result.
>
> Austin
>
> Symon wrote:
>
> > Hi Peter,
> > If the pin has 10 Ohms of drive impedance the initial sent pulse
> > will be less than 3.3V, in fact 3.3V * 50/(10+50) = 2.75V, as the 10
> > Ohms driver drives a 50 Ohm line. The reflected signal from the
> > unterminated far end is then 2* 2.75V = 5.5V. This reflected pulse
> > then increases the voltage at the pin to 3.667, as it's driven from 50
> > Ohms into a 10 Ohm impedance to VCC = 3.3V. This is less than the
> > absolute maximum rating of 3.75V. Hooray!
> > As you say, this calculation disregards the attenuation due to
> > the trace propagation function, which will further reduce the
> > amplitude of the pulse as it travels back and forth down the
> > transmission line(pcb trace). This is caused by skin effect and stuff.
> > I guess you could also reduce the drive strength of the pin from the
> > default 12mA, to increase the source impedance.
> > The receiver pin is the one that gets the big hit.
> > cheers, Symon.
> >
Article: 60805Hi All Has anyone successfully implemented USB 2.0 or USB 1.1 protocol in Altera Device. If yes, can you pls start me off. I'm not able to make any progress in this. I have found couple of sites in ths area, but always end towards a brick wall. Help Pls CheerioArticle: 60806
> The receiver pin is the one that gets the big hit. So how bad is that hit? How good are the protection diodes? If the clamp diodes are any good they will reduce the reflection and make things easier back at the transmitter. -- 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: 60807
>All smart chip manufacturers try to err on the side of zero or negative >hold time, and accept the corresponding larger set-up time. Is there anything in the physics that encourages this? My reading is that it simplifies the software. If the hardware guys will promise that the prop time is enough to cover the hold time plus clock skew, then the software doesn't have to check that case. >An unduely large set-up time sacrifices max clock rate. >A positive hold time can mean unreliable operation at any speed. :-( Only if the software doesn't check for that case. -- 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: 60808
Hi, I have a design that transmits data trough a cable and sends the clock along. At the receiver side the clock is going trough a dcm when i disconnect the cable the dcm doesn't lose his lock (somtimes it does). there is some rubbisch in the hanging cable (status bit is toggling) what could be the problem. the rubbisch in the cable is not good enough to filter a clock out of it. Even if there is no rubbisch the lock doesn't dissapear (have measured it) Yours Bram -- ================================================== Bram van de Kerkhof OCE-Technologies BV Building 3N38 St. Urbanusweg 43, Venlo, The Netherlands P.O. Box 101, 5900 MA Venlo ================================================== Direct dial : +31-77-359 2148 Fax : +31-77-359 5473 ================================================== e-mail : mailto:bvdk@oce.nl ================================================== www : http://www.oce.nl/ ==================================================Article: 60809
"Valeria Dal Monte" <aaa@bbb.it> writes: > Some days ago Xilinx did workshops in many european states. > Why Italy was excluded? > A few years ago Peter Alfke told me that Italy represents a rather small share of the European market for Xilinx. I guess that's the reason... -ArrigoArticle: 60810
Chen Wei Tseng <chenwei.tseng@xilinx.com> wrote in message news:<bkn59c$ki52@cliff.xsj.xilinx.com>... > Antti, > > iMPACT does allow user to download, verify, get device ID via JTAG. For > other functions such as EXTEST, INTEST, etc, you can shift in such > instructions with iMPACT's Debug Chain functionality. This feature > allows you to move through the 16 TAP controller states and shift in TDI > data. > > With 6.1i iMPACT you'll be able to genrate and program the Xilinx part > with SVF (via inbuild XSVF player function). > > If iMPACT isn't detecting the Parallel Cable for you, please see Xilinx > solution 15742 for debugging tips and contact the Xilinx hotline support > for further issues. > > Regards, Wei > Xilinx Applications > > Antti Lukats wrote: Dear Xilinx Applications! thank you for the answer, but it is no anser actually, - see using ISE 5.2, if I want to play a STAPL file that programs a 2MB Flash connected to a Xilinx FPGA how do I do it with Cable IV? Answer is I CAN NOT. With Cable III there there are no problems, I just execute the STAPL with a STAPL player and its all done. Your answer about using 'Debug Chain Functionality' is really really stupid! As far as I can see it is only possible todo it in iteractive mode. To programa 2MB flash, it takes maybe over 10,000,000,000 transactions on JTAG port (depends on chain lenght) if I do it manually by clicking on buttons in iMpact - ridiculuous. if new iMpact allows SVF playback its a little bit help, but iMpact is really really a nighmare (as others on this list have said also) thanks for your time (well, you get paid for it) antti lukats PS my statement stays: Cable IV is not useable for Boundary Scan. PPS if you now say I a stupid and should read iMpact manual, then FYI I am not and I just did: "bsdebug [-start] [-reset] [-stop] [-tms 0|1] [-tdi 0|1] [-tck <number>] [-loop <number>] :Executes the Boundary-Scan Debug instruction which shifts in the instruction and data values specified by -tms and -tdi." There is no way to capture TDO !!!!! what means the debug chain batch command can not be used for boundary scan.Article: 60811
"SneakerNet" <nospam@nospam.org> wrote in message news:<fIObb.156268$JA5.3828849@news.xtra.co.nz>... > Hi All > > Has anyone successfully implemented USB 2.0 or USB 1.1 protocol in Altera > Device. If yes, can you pls start me off. I'm not able to make any progress > in this. I have found couple of sites in ths area, but always end towards a > brick wall. if you dont say what your problem is how could one help? the USB cores available are working out of box for Xilinx, for altera you need to change the technology dependant portions and it should again work. anttiArticle: 60812
"Hal Murray" <hmurray@suespammers.org> wrote in message news:vmvmv083cu824@corp.supernews.com... > >All smart chip manufacturers try to err on the side of zero or negative > >hold time, and accept the corresponding larger set-up time. > > Is there anything in the physics that encourages this? Before FPGA's, when gates and FF's were wired together, hold time would limit what you could wire together. My previous example, the common 7474 dual D flip-flop with the Qbar output to the D input would, technically fail. (I don't know if I ever tried it.) 74LS74 had a 0 hold time. > My reading is that it simplifies the software. If the > hardware guys will promise that the prop time is > enough to cover the hold time plus clock skew, then > the software doesn't have to check that case. > > >An unduely large set-up time sacrifices max clock rate. > >A positive hold time can mean unreliable operation at any speed. :-( > > Only if the software doesn't check for that case. Only if you can guarantee that the software check works for all voltages and temperatures at which the device might run. Ony might hope that they scale the same, but I don't know that it is guaranteed. -- glenArticle: 60813
I have added a keyboard controller to my soc implementation. http://www.c-nit.net SumitArticle: 60814
Hi guyes If any body interested in FSK modem based on FPGA PLZ contact me : www.hazmi.itgo.com Thanks , HaythamArticle: 60815
Peter Alfke <peter@xilinx.com> wrote in message news:<3F6F1C81.16801DD9@xilinx.com>... > My first answer is: look it up on google. You get 747 hits! > Question: Do you need any more? > The parts do not exist anymore, so why do you need the data sheet? > > Peter Alfke, Xilinx > > "H.Azmi" wrote: > > > > Hi guyes , > > Does any body have datasheet for XC6216 ? Hi Peter, there are people who would like to have XC2616, I actually tried to buy XC6216 development board at ebay (Ray Andraka was selling) but I was too late :( as much as I know XC6216 is the only Xilinx device that has full public bitstream documentation (or had at least) also for XC6216 there is free JERC6K JBits system inclusive Java sources still downloadable from xilinx download site :) so there are historic and educational reasons to have XC6216, if I would have that board would use it for P&R tool testing, as bitstream is known and array is relativly simple. anttiArticle: 60816
On 18 Sep 2003, Bob wrote: > Hello Jake/Ray > > I appreciate two esteemed people like yourselves offering me your > advice. > > I would rather infer than instantiate (if that doesn't sound too > rude). [cut] I suspect that inferring vendor-specific embedded primitives (like LUTs, RAM, etc) is one of the few situations where logic simulation is not reliable, as the implementation depends a lot on the translator. At least I had problems with xilinx BRAM that I could explain only in this way. Try at least one post-PAR simulation to see if the LUT behaves as you expect in all operating modes. Tullio Univ. of MarylandArticle: 60817
John_H wrote: > "Rene Tschaggelar" <some@know.me> wrote in message > news:da916fbbcc79413230e067ade436a0d4@news.teranews.com... > >>Tom Derham wrote: >> >>>[snip] >>>Question: how long must the pulse from the first clock be, to ensure > that it >>>triggers the second clock? As I see it, if it is one clock cycle long, > then >>>the second clock should trigger on the next clock rising edge (providing > the >>>sum of clock propagation and the 2nd clock flip-flop setup is less than > one >>>clock cycle)... but functionally the pulse will fall back at the moment > it >>>is triggered (one cycle later), so will only work if the hold time of > the >>>flip-flop is less than the clock propagation. >>>Is this safe? Does the pulse need to be longer? Will the simulation > tools >>>realise if there is a problem here? >>You can delay the output signal with another FF and 'OR' its input and > output. >>That gives you another clock cycle in length. > > Rene, wouldn't this enable the second counter twice? I'd run a simulation on that and only extend the pulse if required. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 60818
Hello, I'm working on a project with XC2V2000 and ISE4.2. Does anyone know, if there is a location constraint to locate a SINGLE PROCESS on a certain quadrant or slice-range? Thank you, MatthiasArticle: 60819
Hi, I am trying to use the embedded ppc in Xilinx Virtex 2 pro FPGA to reconfigure the same. I have gone thro the embedded design applications , xapp 058, xapp503. As I see, those applications had external processors, but what i am trying to achieve is store bit files in PROM , boot with a file , later, access the other file from PROM and reconfigure the entire device. It seems, System ACE Cf is a promising solution to this. But I need help on how to interface PROM with PPC , I am having Xilinx HW AFX prototye demo board, xc2vp4, ff672 -6 package. the board has couple of 4MB PROM's which i need to access from PPC. If not, i have one 8MB SRAM which can be configured using the EDK tools. To put it short, I am trying to load bit streams on the fly by configuring PPC I would appreciate any advice and help Early thanks for the time spend to reply. Ram University of OklahomaArticle: 60820
You missed the point.. I'm the engineer who has to deal with his Boss quoting specs which I know are out moded was just mentioning the problem as I have come across this before.. You and I both know that a single FPGA is far more reliable than 500 transistors.. Just sometimes the piece of paper is the piece of paper.. and unless you find a standards organisation willing to certify a new, better method, you get left with more paper ...then, of course, you have to convince my boss :-) but at the moment we usually don't both with reliability reports.. there are just usual design practices used to keep the reliability as high as possible... like don't use a 5V cap on a 5V rail :-) Am not designing for space or aircraft so I have that luxury. Simon "Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message news:3F6F09E4.5865169E@xilinx.com... > Simon, > > That is for the lazy folks: if you know the reliability (from studies, > manufacturers data, etc.) you can choose to replace the "count method" with the > real data (wow, what a concept!). > > The "count method" is there as a last resort, if there is no other way to gauge > reliability. Once you see the count method numbers, it should send you > screaming to get the real data. The standards bodies know this, and understand > this, it is just that lazy engineers just keep filling out the forms as if they > were still designing in 1968 .... > > Our reliability group is happy to provide the latest and most up to date > reliability information for completing these studies properly (per the > standard). Please make the request thru the hotline. > > Austin > > Simon Peacock wrote: > > > I think that's because one of the standards counts transistors in its MTBF.. > > so a PAL is more reliable than an FPGA but less reliable than an HC00. > > > > Simon > > > > "Peter Alfke" <peter@xilinx.com> wrote in message > > news:3F6B9895.CB08B483@xilinx.com... > > > I think the answer is " more than 100 million, but less than 300 million". > > > > > > We are caught between embarrassment: "that's how many we need" and > > > pride: "that's how good we are, to be able to make and sell that many > > > for a reasonable price". > > > > > > An then there still are some people who really and seriously (!) think > > > they can calculate device reliability and MTBF from the total number of > > > transistors. These guys do not seem to die out, even though we have told > > > them, and proven to them, again and again, that such calculations are > > > utter nonsense. > > > > > > So Ray is right, you would need another seven or eight fingers... > > > Peter Alfke > > > ======================== > > > Ray Andraka wrote: > > > > > > > > More than you can count on both hands and feet, even if you count in > > binary > > > > :-) > > > > > > > > Arnaldo Oliveira wrote: > > > > > > > > > Hi! > > > > > > > > > > Could someone tell me how many transistors are integrated on the > > XC3S5000 > > > > > Spartan-3 device? > > > > > Thank You. > > > > > Arnaldo. > > > > > > > > > > -- > > > > > > > > -- > > > > --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: 60821
ramnathanm@yahoo.com (Ram) wrote in message news:<380c480e.0309230254.138b85@posting.google.com>... > Hi, > I am trying to use the embedded ppc in Xilinx Virtex 2 pro FPGA to > reconfigure the same. what you want is notreadily available SystemACE CF is a real cool solution, but you cant use that the config PROM could theoretically be reprogrammed by the same FPGA it does configure but this is a realy dangerous technic, if something goes wrong then the system fully dead. Atmel FPSLIC appnote descibes similar thing, the FPGA+CPU are booted from config memory then the configuration memory is reprogrammed using config interface (in that case I2C). then its rebooting with new configuration. similar could theoretically work on Xilinx FGPA and config but you would need to use JTAG interface to reprogram the platfrom flash. as of reconfig from ram, etc, read the threads about partial reconfig. anttiArticle: 60822
do_not_reply_to_this_addr@yahoo.com (Sumit Gupta) wrote in message news:<ae680d56.0309230000.265514b4@posting.google.com>... > I have added a keyboard controller to my soc implementation. > > http://www.c-nit.net download of cpu.v and soc.zip are bad links http: 404 not found please fix anttiArticle: 60823
Matthias Müller <mur@iis.fhg.de> wrote in message news:<3F701770.AD2A812@iis.fhg.de>... > Hello, > I'm working on a project with XC2V2000 and ISE4.2. > Does anyone know, if there is a location constraint to locate a SINGLE > PROCESS on a certain quadrant or slice-range? > Thank you, > Matthias I guess you have to wrap the process into single module and constrain that module anttiArticle: 60824
Glen Herrmannsfeldt wrote: > > "Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message > news:3F6F09E4.5865169E@xilinx.com... > > Simon, > > > > That is for the lazy folks: if you know the reliability (from studies, > > manufacturers data, etc.) you can choose to replace the "count method" > with the > > real data (wow, what a concept!). > > > > The "count method" is there as a last resort, if there is no other way to > gauge > > reliability. Once you see the count method numbers, it should send you > > screaming to get the real data. The standards bodies know this, and > understand > > this, it is just that lazy engineers just keep filling out the forms as if > they > > were still designing in 1968 .... > > There is a story I heard some years ago, related to statistical physics, but > it should work for any statistics problem. A person was told that the > probability of a bomb being on an airplane was 1 in 1000, but the > probability of two bombs was 1 in 1000000. To be safe, he always brought > his own bomb on the plane. (I think those are the numbers in the story, > which has no relation to any real planes or real bombs.) > > The important thing in a large number of problems is statistical > independence. When all the transistors on a single chip are made at the > same time, using the same process, the probability of one failing is not > statistically independent of another failing. A bad batch of any of the > chemicals that go into the processing, various mechanical problems that > could occur, or any number of other events tend to affect all the > transistors on a chip equally. Without statistical independence any count > based method will fail, just like in the bomb story. That would be true for some failure modes due to incorrect construction. But there is a very low failure rate due to "wear" of the semiconductor. This would include electro-migration, void migration and a host of other effects I don't remember. If you have a failure rate per transistor for a given process, then counting transistors can be applied to these failure modes. The question is whether these modes are significantly more or less likely to make the chip fail than other external failure modes like the PSU overvolting or someone dropping a hammer on the chip. -- 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
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