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
On Jan 11, 9:31 pm, John McCaskill <jhmccask...@gmail.com> wrote: > On Jan 11, 2:28 pm, ratemonotonic <niladri1...@gmail.com> wrote: > > > Hi all , > > > Is there any place where I can download opb emc 1.10.b as my lates > > EDK istallation doesnt have it? > > > BR > > Rate > > What version of EDK are you using? opb emc 1.10.b is still in 9.1, > but it has been deprecated for a while and EDK does not show > deprecated cores by default. > > You can have EDK show deprecated cores by going to Edit->Preferences->IP Catalog and IP Config Dialog and checking the Display Deprecated > > IP Cores in IP Catalog check box. > > If it really is not there, you can download older versions of Xilinx > software from the electronic fulfillment center if you have registered > for it. > > Regards, > > John McCaskillwww.FasterTechnology.com Hi John , I am on 9.2i and for some reason emc 1.10.b has been removed. And it is a problem for us as all our reference desgins are based on it. There is enough work to move to 2.00.a to justify me looking for 1.10.b. about the electronic fufillment center , we have bought EDK software from avnet , does it still mean we can use electonic fullfilment center? BR RateArticle: 128001
Which board do you use ? Is it the Suzaku ? On Thu, 10 Jan 2008 18:19:10 +0100, ratemonotonic <niladri1979@gmail.com> wrote: > Hi All , > > I new to FPGA development tools from xilinx. I am following an > application note number XAPP924 to use EPC module to inteface > SMSC91C111 with a microblaze ( the application note is for PPC I have > replaced it with uBlaze). > > This doesnt work I can only read lower bytes of the registers in > SMSC , that too not for all registers? Has any one else encountered > same problem? > > BR > rateArticle: 128002
On Jan 12, 5:08 am, ratemonotonic <niladri1...@gmail.com> wrote: > On Jan 11, 9:31 pm, John McCaskill <jhmccask...@gmail.com> wrote: > > > > > On Jan 11, 2:28 pm, ratemonotonic <niladri1...@gmail.com> wrote: > > > > Hi all , > > > > Is there any place where I can download opb emc 1.10.b as my lates > > > EDK istallation doesnt have it? > > > > BR > > > Rate > > > What version of EDK are you using? opb emc 1.10.b is still in 9.1, > > but it has been deprecated for a while and EDK does not show > > deprecated cores by default. > > > You can have EDK show deprecated cores by going to Edit->Preferences->IP Catalog and IP Config Dialog and checking the Display Deprecated > > > IP Cores in IP Catalog check box. > > > If it really is not there, you can download older versions of Xilinx > > software from the electronic fulfillment center if you have registered > > for it. > > > Regards, > > > John McCaskillwww.FasterTechnology.com > > Hi John , > > I am on 9.2i and for some reason emc 1.10.b has been removed. And it > is a problem for us as all our reference desgins are based on it. > There is enough work to move to 2.00.a to justify me looking for > 1.10.b. > > about the electronic fufillment center , we have bought EDK software > from avnet , does it still mean we can use electonic fullfilment > center? > > BR > Rate We bought our software through Avnet as well. More info about the electronic fulfillment center is at: http://www.xilinx.com/ise/esd/index.htm Have you used previous versions of EDK? If so, you can just copy the core from an older version of EDK, which is what I was suggesting that you get from the fulfillment center. The cores that come with EDK are located in: $EDK\hw\XilinxProcessorIPLib\pcores. Are the reference designs you mention your designs for your product, or are they designs that came with something you bought? I have been using the opb_emc_v2_00_a since from the start for our current products so I did not have to upgrade. What sort of problems does it present? opb_emc_v2_00_a has been around since at least 6.3.2 which is also when v1_10_b was deprecated, so it does not surprise me that Xilinx finally dropped v1_10_b from their distribution. Regards, John McCaskill www.FasterTechnology.comArticle: 128003
> Are the reference designs you mention your designs for your product, >or are they designs that came with something you bought? Thanks so much for helping me our .It is a Avnet evaluation board called the spartan 3 mini module with an external ethernet mac/phy chip which is interfaced with uBlaze with emc 1.10.b, in demo projects, as it is not present in the repository , the project doesnt open. I tried to replace it with 2.00.a(matching the settings) but it doesnt work I dont have a clue what the problem is , so i thought to source 1.10.b to get a base system working. >Have you used previous versions of EDK? If so, you can just copy the >core from an older version of EDK, which is what I was suggesting that >you get from the fulfillment center. The cores that come with EDK are >located in: $EDK\hw\XilinxProcessorIPLib\pcores. no I havent this is my first project with xilinx tools and boy what a ride! My repository ($EDK\hw\XilinxProcessorIPLib\pcores) definately doesnt have it. I just wish there is a simple way to get this IP. I will register my software at the fulfillment center and see if i get access to the IP core. Cause right now I only get access to ISE 9.2 evaluations.Article: 128004
On 12 Jan, 14:04, PFC <li...@peufeu.com> wrote: > =A0 =A0 =A0 =A0 Which board do you use ? Is it the Suzaku ? > > On Thu, 10 Jan 2008 18:19:10 +0100, ratemonotonic <niladri1...@gmail.com> = =A0 > wrote: > > > > > Hi All , > > > I new to FPGA development tools from xilinx. I am following an > > application note number XAPP924 to use EPC module to inteface > > SMSC91C111 with a microblaze ( the application note is for PPC I have > > replaced it with uBlaze). > > > This doesnt work I can only read lower bytes of the registers in > > SMSC , that too not for all registers? Has any one else encountered > > same problem? > > > BR > > rate- Hide quoted text - > > - Show quoted text - No it is Avnet/memec Spartan 2 Mini module. see link - http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D25724%2526CCD%= 253DUSA%2526SID%253D32214%2526DID%253DDF2%2526SRT%253D1%2526LID%253D32232%25= 26PRT%253D0%2526PVW%253D%2526PNT%253D%2526BID%253DDF2%2526CTP%253DEVK,00.htm= l BR rateArticle: 128005
-jg wrote: > John_H wrote: >> -jg wrote: >> >> Your argument was that two out of every three 300 MHz clock edges don't >> even have a CHANCE of creating the metastable event. > > Correct. You can roll the dice once, but not three times. > >> Consider the >> "controlled" asynchronous version of this test where the 300 MHz clock >> is phase locked to the 50 MHz clock being sampled and the 300 MHz clock >> is phase shifted across the full 10ns of a single bit period. This 10 >> ns phase shift produces three capture window crossings. If you use a >> 200 MHz clock and shift those 10 ns, you will have two window crossings. > > I'm not sure I follow?. Peter's test circuit uses the clock for two > different things. > Once to sample the data stream and again to set the settling window, > to decide > if metastable events occured. > Yes, this is nice and simple, but can give the illusion that the > faster clock gives more transistion-settling-event samplings. If you had a fixed delay to measure the metastability delay rather than the sampling clock, you remove that second clock from the situation. If you think of statistics and imagine the capture window *is* 33 femtoseconds then the chance of *any* random edge hitting that capture window in the 10 ns data period (provided by the 50 MHz clock being sampled) is 33fs/10ns. If you could produce 300 million sampling edges (at any frequency, doesn't matter) where the edges increment in phase offset relative to the 10ns period by 33fs each step (assuming zero jitter *here*) then one and only one clock will cause a metastable event. When 300 million edges are presented asynchronously, these 300 million edges have a flat statistical distribution across the 10ns period. >> If your sample clock frequency could approach infinity, you would >> *always* have a metastable event captured. > > Yes, a good limit case (assuming zero jitter) : This case would have > these events every 10ns (not every clock) - you cannot have more > transistion-settling-events than transistions :) An infinite clock limit means metastability with or without jitter. Your assumption that jitter would be important in this limit case helps reinforce my view of your mathematical reasoning. > With a difference of 3:1 between CLK and Edge rates, the distinction I > am trying to make > is not large on the scale of metastable values, but I would derive a > different window-size than Peter, from the same data. > > Should be easy enough to verify, and also get better test vehicles for > more accurate > window sizes. If I was making chips, I'd like to know that number as > precisely as possible > (even tho it is way below any jitter, and some would say 'who > cares?') because it could indicate if a new process was actually > better than an older one. > > -jg So do the darned verifications! You appear not to believe the many verifications that Peter HAS DONE. Your nay-saying an expert on this issue is silly and annoying. I wouldn't bother trying to underscore the validity after these first attempts if this was just a private discussion. I'm concerned that people who don't know much about metastability would see this conversation as an indication that the issues aren't clear. Are there any other well defined issues you'd like to cast doubt upon? I mean... while we're at it. - John_HArticle: 128006
John_H wrote:
> I'm concerned that people who don't know much about
> metastability would see this conversation as an indication that the
> issues aren't clear.
I agree.
This same discussion is dug up about once a year.
This is where electronics meets quantum mechanics.
Many smart people have been fooled on this subject.
-- Mike Treseler
Article: 128007Eric Smith wrote: > With the possible exception of the Socket 1207 parts, for which documentation > is not available, the AMD processors don't have dual memory channels, > despite widespread claims. They have a single channel that can operate in > either 64-bit or 128-bit width (plus optional ECC). Using 128-bit width has > obvious benefits, but interleave is not one of them. Well, fixed 128-bit width is pretty much the same thing as dual 64-bit with a fixed interleaving ratio. Specifically, interleaving at 8-byte boundaries. -hpaArticle: 128008
HI, Symon wrote: > "Michael Laajanen" <michael_laajanen@yahoo.com> wrote in message > news:5uoh19F1id6lfU1@mid.individual.net... > >>Why not just concatenate the files? >> >>/michael >> > > Hi Michael, > For the same reason that I don't concatenate all my VHDL files into one big > whopper. > HTH., Syms. > > Maybe I missunderstand you but I ment concatenate them prior to the P&R run. /michaelArticle: 128009
Hello, I've observed a failure of one of our Virtex4-based products that is a bit puzzling. The device had been in operation for several weeks before failing, and is among a run of a couple hundred. I've dissected the specimen, and the Virtex4 appears to draw a large amount of current and gets hot immediately upon power-up. It does not configure or show any signs of life. Aside from the possibility of this being induced by a manufacturing defect that took its time to show up, can anyone think of any design- related causes of a failure like this? Thanks in advance, Mike.Article: 128010
<msn444@gmail.com> wrote in message news:c7463bc7-1443-4ee1-9de6-5b602825bb8e@m77g2000hsc.googlegroups.com... > Hello, > > I've observed a failure of one of our Virtex4-based products that is a > bit puzzling. The device had been in operation for several weeks > before failing, and is among a run of a couple hundred. I've dissected > the specimen, and the Virtex4 appears to draw a large amount of > current and gets hot immediately upon power-up. It does not configure > or show any signs of life. > > Aside from the possibility of this being induced by a manufacturing > defect that took its time to show up, can anyone think of any design- > related causes of a failure like this? > > Thanks in advance, > > Mike. Do any of the power supplies EVER exceed the maximum allowed? You should carefully check power-on, operating, and power-off conditions with a high speed scope. This is the only thing that I've ever done that truly damaged an FPGA. Another (less likely) possiblility is overcurrent on inputs due to driving them above and/or below the supplies. What about over-temperature? However, it would have to get effing hot (>125C ?). I can't think of anything that would bother the thing. BobArticle: 128011
I've had issues in the past with this very thing happening on a V2PRO part. It was due to power supplies not coming up in the right sequence, or not being monotonic in their ramp-up; thus causing the FPGA to get hot and drawing enough current to drop my low voltage supply. One way to test if this is your problem would be to hold off configuration (I usually design in a push-button on the PROG_B line) until all the supplies are up and stable. If the problem goes away, you can be fairly confident that it is a power supply ramp-up/sequencing issues. <msn444@gmail.com> wrote in message news:c7463bc7-1443-4ee1-9de6-5b602825bb8e@m77g2000hsc.googlegroups.com... > Hello, > > I've observed a failure of one of our Virtex4-based products that is a > bit puzzling. The device had been in operation for several weeks > before failing, and is among a run of a couple hundred. I've dissected > the specimen, and the Virtex4 appears to draw a large amount of > current and gets hot immediately upon power-up. It does not configure > or show any signs of life. > > Aside from the possibility of this being induced by a manufacturing > defect that took its time to show up, can anyone think of any design- > related causes of a failure like this? > > Thanks in advance, > > Mike.Article: 128012
John_H wrote: > > So do the darned verifications! You appear not to believe the many > verifications that Peter HAS DONE. Your nay-saying an expert on this > issue is silly and annoying. You do not seem to be reading what I am writing. I have no issue with Peter's measurements, or his test circuits, but I do have a small issue with the derived window size, that he then calculates from those measurements. As I have already stated it is somewhat academic, and does an end user care if it is 33 atto seconds, or 100 atto seconds ? Both are very small numbers. . -jgArticle: 128013
-jg wrote: > > John_H wrote: >> So do the darned verifications! You appear not to believe the many >> verifications that Peter HAS DONE. Your nay-saying an expert on this >> issue is silly and annoying. > > You do not seem to be reading what I am writing. > > I have no issue with Peter's measurements, or his test circuits, > but I do have a small issue with the derived window size, that he > then calculates from those measurements. > > As I have already stated it is somewhat academic, and does > an end user care if it is 33 atto seconds, or 100 atto seconds ? > > Both are very small numbers. > . > -jg And the discussion on why those numbers are valid appears to escape you. Just because 2 of the three clocks "never have a chance" of causing an event doesn't let you limit the even statistical distribution of edge position within the period to the "single edge closest to the window." If the two clocks were different by a factor of 100 rather than a factor of 3, your suggestion on calculating the window size would be much less than academic. I know you have an issue with the derived window size. I have read your posts. I see why your view of the approach is wrong. I've tried to give you different directions to look at the problem to see why your observations are less than complete. I like to see people understand. I don't see it here. - John_HArticle: 128014
John_H wrote: > > And the discussion on why those numbers are valid appears to escape you. > Just because 2 of the three clocks "never have a chance" of causing an > event doesn't let you limit the even statistical distribution of edge > position within the period to the "single edge closest to the window." > > If the two clocks were different by a factor of 100 rather than a factor > of 3, your suggestion on calculating the window size would be much less > than academic. > > I know you have an issue with the derived window size. I have read your > posts. I see why your view of the approach is wrong. I've tried to > give you different directions to look at the problem to see why your > observations are less than complete. > > I like to see people understand. I don't see it here. There are also two error types, the average one, and the peak one. Sometimes in engineering, we like to think about worst case, as well as averages. Someone else mentioned a locked metastable generation system, ie one that deliberately tries to be metastable. Suppose I have a 1MHz data rate, and choose a 1MHz (+ErrN) Clock, -or- a 100MHz(+ErrM), and assume a 'nominally' real system with nice round numbers of a 0.1fs window, and 0.1ps jitter Q1: Can these widely variant clocks ever give the same peak error rates ? Q2: Can the error rate ever go above one per microsecond ? -jgArticle: 128015
I wrote: > With the possible exception of the Socket 1207 parts, for which documentation > is not available, the AMD processors don't have dual memory channels, > despite widespread claims. They have a single channel that can operate in > either 64-bit or 128-bit width (plus optional ECC). Using 128-bit width has > obvious benefits, but interleave is not one of them. "H. Peter Anvin" wrote: > Well, fixed 128-bit width is pretty much the same thing as dual 64-bit > with a fixed interleaving ratio. Specifically, interleaving at 8-byte > boundaries. Historically, having two banks of interleaved memory meant that if bank 0 was busy reading or writing an even word address, bank 1 could start an access to ANY odd word address, not just n+1. It is my understanding that that was the reason for inventing interleave rather than simply making the memory word longer. HPA suggested to me in private email that that sort of interleave didn't seem useful when the cache is tranferring whole cache lines, to which I replied: > It just means that you'd want the interleave size to be the cache line > size. There's no technical reason that a CPU with two memory "channels" > shouldn't do that. But as I mentioned previously, the AMD processors > don't actually have two channels, just one wide channel. > For a single core (single-threaded) doing that might not produce much > benefit, but it certainly could be useful with multiple cores or > threads. > On a multi-socket Opteron system you effectively get that if you > configure the memory controllers in the multiple chips for interleave > rather than linear addressing, but you have the additional hypertransport > latency for accessing memory attached to another socket's memory > controller.Article: 128016
On Jan 11, 5:57 pm, "Eric Crabill" <eric.crab...@xilinx.com> wrote: > Hi, > > It could be that you are trying to put LVDS outputs on banks that don't > support LVDS output. In Spartan-3A and Spartan-3AN, I believe you can only > implement LVDS outputs on the top and bottom banks of the die. Arrrrgh, indeed, that is it. I assigned my pinouts based on the PDF pinout from http://www.xilinx.com/support/documentation/data_sheets/s3a_pin.zip The pins I chose for my LVDS outputs were on Bank 3. The pins I chose were all labeled as I/O with names like L01N_3 and L01P_3. Naturally, I assumed that I/O mean I/O for the differential signaling as well as single-ended. But yes, the table in the user guide does indicate that 3AN devices allow LVDS outputs on banks 0 and 2 only. Perhaps a little note on the pinout page clarifying that would help. > For reference, a DIFFSTB is an IOB that is a DIFFerential Slave on the Top > or Bottom of the die. A DIFFSLR, as you might imagine, is DIFFerential > Slave on the Left or Right of the die. You also referenced some site types > with an M in them instead of an S, those are Master site types. What the > message is unsuccessfully trying to communicate is that you've got something > that needs to be on a DIFF*TB site, but your location constraint is for a > DIFF*LR site. I assumed that to be the case, but I was rather astonished that this isn't documented anywhere. > I cannot say for certain about the completely unconstrained I/O test you > ran, but I suspect that the placer either wasn't able to figure out a > solution to your design I/O requirements without some hints, or that you may > have more LVDS outputs in your design than will fit on the top and bottom > banks. Actually, the problem is neither: it wasn't completely unconstrained I/ O. I left other pin assignments as is and unconstrained just the LVDS stuff. I designated bank 2 as 3.3V, so the tools couldn't assign LVDS_25 signals to it. Bank 0 was pretty full up with other things. Project for Monday is to create a new pinout. -aArticle: 128017
On Jan 12, 10:24=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > -jg wrote: > > > John_H wrote: > >> So do the darned verifications! =A0You appear not to believe the many > >> verifications that Peter HAS DONE. =A0Your nay-saying an expert on this= > >> issue is silly and annoying. > > > You do not seem to be reading what I am writing. > > > I have no issue with Peter's measurements, or his test circuits, > > but I do have a small issue with the derived window size, that he > > then calculates from those measurements. > > > As I have already stated it is somewhat academic, and does > > an end user care if it is 33 atto seconds, or 100 atto seconds ? > > > Both are very small numbers. > > . > > -jg > > And the discussion on why those numbers are valid appears to escape you. > =A0 Just because 2 of the three clocks "never have a chance" of causing an= > event doesn't let you limit the even statistical distribution of edge > position within the period to the "single edge closest to the window." > > If the two clocks were different by a factor of 100 rather than a factor > of 3, your suggestion on calculating the window size would be much less > than academic. > > I know you have an issue with the derived window size. =A0I have read your= > posts. =A0I see why your view of the approach is wrong. =A0I've tried to > give you different directions to look at the problem to see why your > observations are less than complete. > > I like to see people understand. =A0I don't see it here. > > - John_H This discussion is not about politics or religion: This is science, and there is only ONE correct answer. But the newsgroup is a poor vehicle to convince someone who does not want to "get it". This debate should not go on forever... On a related subject: It amazes me that there is so much talk and fear about metastability, but nobody gets his fingers dirty and performs real measurements. I published "my" original circuit 18 years ago (!), and to my knowledge no university has picked this up as a simple challenge. Any competent student can grasp the concept in less than a week, and anybody with the skill to configure FPGAs or CPLDs can duplicate these experiments in a short time with simple equipment, ( an eval board, a variable clock source, and a stop watch), and every experiment usually runs for less than an hour. Why does nobody try to PROVE me (and Xilinx) right or wrong? I have publicly (in this newsgroup) offered my assistance, but nobody responded. IC manufacturers (including Xilinx) do not seem to see metastabilty as a very important subject. There are always more burning design issues, like raw speed, functionality, size and power consumption that take precedence. Further "metastability-hardening" might compromise some of the other important aspects. FPGAs have up to hundreds of thousands of flip- flops, and only a few of them will ever be challenged with metastability. We all know that we can never avoid metastability, but I wanted to have quantitative proof that we can live with it, and have ways to design around it. Is a one-man effort sufficient for that ? Thanks for your trust, but it feels a bit lonely... Peter AlfkeArticle: 128018
-jg wrote: > > John_H wrote: >> And the discussion on why those numbers are valid appears to escape you. >> Just because 2 of the three clocks "never have a chance" of causing an >> event doesn't let you limit the even statistical distribution of edge >> position within the period to the "single edge closest to the window." >> >> If the two clocks were different by a factor of 100 rather than a factor >> of 3, your suggestion on calculating the window size would be much less >> than academic. >> >> I know you have an issue with the derived window size. I have read your >> posts. I see why your view of the approach is wrong. I've tried to >> give you different directions to look at the problem to see why your >> observations are less than complete. >> >> I like to see people understand. I don't see it here. > > There are also two error types, the average one, and the peak one. > Sometimes in engineering, we like to think about worst case, as > well as averages. > > Someone else mentioned a locked metastable generation system, > ie one that deliberately tries to be metastable. > > Suppose I have a 1MHz data rate, and choose a 1MHz (+ErrN) Clock, > -or- a 100MHz(+ErrM), and assume a 'nominally' real system with > nice round numbers of a 0.1fs window, and 0.1ps jitter > > Q1: Can these widely variant clocks ever give the same peak error > rates ? > Q2: Can the error rate ever go above one per microsecond ? > > -jg There's a minute possibility the error can happen on several consecutive clock cycles so yes - the instantaneous rate can far exceed one event per statistically-even distribution of edges because they have probabilities of hitting the window, not certainties. Over a long enough period of time (high enough population) the error will approach the statistical expectations. If your example is the MLL - the Metastability Locked Loop - then jitter has a strong impact but to determine the actual error rate, the jitter distribution has to be part of the equation. There are too many ways to describe jitter. If the MLL is ideally centered, then the percent of population of the 0.1fs window has to be determined relative to the "0.1ps" jitter distribution. The 0.1ps could be RMS or peak-to-peak with any of several multiplying factors from RMS. But IT DOESN'T MATTER. For determining the sampling window size, an even statistical distribution across a fixed period will give you the best statistical results. Even in the totally asynchronous case, the possibility of hitting the same window multiple times in a row exists; it's just a very small probability. If you want to think "peak error rates" you could envision a system similar to the originally proposed 300MHz/50MHz system (that produces an average of 1 event per second) and have the relative frequency offset be so small that it take a minute for the sampling window to be visited by the "next" consistently located edge in this nearly synchronous design. In that situation, the events will "burst" about 60 errors in a short period of time. In an asynchronous system, the probability that the two signals are that close in frequency for such a long period of time is extremely small. If you want to continue serious discussion on this topic, please mail me directly. I figure others in this group are starting to glaze over when they see this thread belabored more and more. I may need to dig up some resources to start talking specific population ratios for jitter distributions but I could deliver the math. - John_HArticle: 128019
On 2008-01-13, msn444@gmail.com <msn444@gmail.com> wrote: > > Aside from the possibility of this being induced by a manufacturing > defect that took its time to show up, can anyone think of any design- > related causes of a failure like this? Probably not related to your failure, but there was a curious errata for V4 where >unused< MGTs would fail after a few hundred hours of device uptime. The workaround was a dummy MGT driver. I always wondered what the failure mechanism was there! -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 128020
Ben, No mystery: NBTI. Unused MGT front end pmos devices in the differential amplifier circuits could see a significant Vt shift if they were not transitioning. One input high, and one low, and NBTI occurs in the pmos devices, made even worse if the temperature is also high (e.g. like 70 to 85C or hotter). The DCM delay line was also susceptible to NBTI shift, hence the "auto-cal" block being added by the software (to keep delay lines busy switching at a low frequency). Later devices perform these functions by hardware, or design techniques to mitigate the shift are used (no longer an issue after V4). Although the NBTI shift may be demonstrated in a lab, there has never been a case of a field failure for either the MGT, or dCM, due to NBTI. It seems the condition is created by such a specific sequence of temperatures, and static voltages, that unless you are unlucky enough to duplicate, all the pmos shift together, and everything is just fine. NBTI starts out quick, then slows down. A bake without power restores the levels a lot. Just turning things on and off, can mitigate any issues. Very tricky stuff, but once understood, can be dealt with easily. NBTI is over thirty years old, and has been understood and dealt with by the IO designers for a long time. What was a surprise is that MGT front end design (and the DCM delay line) used thinner oxide devices in V4, and didn't expect to see the shift. Foundry practices also helped tune down the effects. This particular "melt-down" scenario is unrelated to NBTI. Common causes: shorts in the package/pcb/solder balls, over-temp of the die (caused by inadequate heatsinking), large over voltage (on core, io, or aux -- causes junction or gate breakdown, this may be power supply, or ESD). Xilinx will issue a RMA (return mechandise authorization) and try to find the cause of failure. However, this is not taken lightly, we request that the customer removes the device using very specific methods, so that we can establish what caused the failure (often customers remove the device, destroying it in the process). A RMA is also something that takes time, and just one failure is not considered a reason to go to all the trouble. Any device returned without authorization is not accepted. AustinArticle: 128021
Hi ! I appologize if that has been dealt with already, though I haven't found an answer in the archives. I have an x86_64 machine running some recent linux (ubuntu hardy dev. amd64), Xilinx ISE 9.2.04i Web version, which I believe is the latest (I have all the necessary 32 bits libs installed), and a 32 bits build of libusb-driver out of git so fully up to date. Things are working fine with the JTAG-3 parallel cable and a SP3 starter kit board. However, I'm having serious issues with the 3AN board and it's built-in USB-JTAG bridge. The udev rules are in place, the firmware seems to be downloaded properly, I can scan the jtag chain fine (I had iMPACT lockup once or twice at that stage but it seems to be allright again, not sure what happened). However, I've never successfully downloaded a config "live" in the FPGA. I've managed to flash the internal flash (the -AN has one). but not download the FPGA only. What generally happens, is that when I choose "Program FPGA only" option, it appears to download fine, I see the progress BAR, it goes all the way, there's a message about successful download at the end, but DONE never comes up and the FPGA never configures (iMPACT then timeouts after a random amount of time, generally about 20s). Actually, the DONE led comes up soon after it starts the download and back off at the end, looks to me like iMPACT is d/l some temp. configuration to the FPGA before doing the full d/l. When I do "Program Flash and Load FPGA", it -mostly- works. That is, it generally succeeds, or eventually fails to configure near the end, just like for a normal download, but generally the flash has been programmed (though I had a couple of cases where the flash wasn't or wasn't properly programmed as the FPGA wouldn't configure afterward). So it seems very erratic to me. The design I'm using is a fairly trivial UART design that I hooked on a simple loopback circuitry to test. I'm fairly new to the whole world of logic design and FPGAs, so it's very possible that I missed something obvious, or a simple setting, but so far, I haven't found anything that makes a difference. I've tried with pretty much any jumper setting for M0..M2, that didn't seem to help. Any help appreciated. I'm an experienced C programmer (a linux kernel person more specifically) so I'd be happy to help track the issue down provided I'm given some pointers into where to look as I'm really not familiar with the whole JTAG operations. Thanks in advance ! Best regards, Ben.Article: 128022
>On a related subject: It amazes me that there is so much talk and fear >about metastability, but nobody gets his fingers dirty and performs >real measurements. >I published "my" original circuit 18 years ago (!), and to my >knowledge no university has picked this up as a simple challenge. Any >competent student can grasp the concept in less than a week, and >anybody with the skill to configure FPGAs or CPLDs can duplicate these >experiments in a short time with simple equipment, ( an eval board, a >variable clock source, and a stop watch), and every experiment usually >runs for less than an hour. Why does nobody try to PROVE me (and >Xilinx) right or wrong? Maybe you did a good enough job that the area isn't interesting any more? I'd like to see data for different temperature, voltage, and rise times. I'm a bit surprised a university hasn't jumped on that one. The rise times are hard to measure and control inside a FPGA. Maybe just long routing vs short routing would be interesting. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 128023
On Jan 13, 3:40=A0pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote: > >On a related subject: It amazes me that there is so much talk and fear > >about metastability, but =A0nobody gets his fingers dirty and performs > >real measurements. > >I published "my" original =A0circuit 18 years ago (!), and to my > >knowledge no university has picked this up as a simple challenge. Any > >competent student can grasp the concept in less than a week, and > >anybody with the skill to configure FPGAs or CPLDs can duplicate these > >experiments in a short time with simple equipment, ( an eval board, a > >variable clock source, and a stop watch), and every experiment usually > >runs for less than an hour. Why does nobody try to PROVE me (and > >Xilinx) right or wrong? > > Maybe you did a good enough job that the area isn't interesting > any more? Nice assumption... > > I'd like to see data for different temperature, voltage, > and rise times. =A0I'm a bit surprised a university hasn't > jumped on that one. > > The rise times are hard to measure and control inside a FPGA. > Maybe just long routing vs short routing would be interesting. Hal, XAPP094 shows the (not-surprising) effect of different voltages. I am sure that the external rise time would be totally swamped out by the gain in the clock buffering. Routing delays just move the time laterally, have no effect on the measurements. Don't expect newer families to be any better. The lowering of supply voltages has a bad impact... (But no need to cry, metastable delays are short enough for almost all cases; and smart users know the remedies for the remaining extreme cases) The obviously better total systems performance of the newer families comes from architecture and systems improvementss, not from a faster gain x bandwidth product in the flip-flops. IMHO, somewhat of a guess... Peter AlfkeArticle: 128024
On Jan 13, 3:54 pm, austin <aus...@xilinx.com> wrote: > Ben, > > No mystery: NBTI. Unused MGT front end pmos devices in the > differential amplifier circuits could see a significant Vt shift if they > were not transitioning. One input high, and one low, and NBTI occurs in > the pmos devices, made even worse if the temperature is also high (e.g. > like 70 to 85C or hotter). The DCM delay line was also susceptible to > NBTI shift, hence the "auto-cal" block being added by the software (to > keep delay lines busy switching at a low frequency). > > Later devices perform these functions by hardware, or design techniques > to mitigate the shift are used (no longer an issue after V4). > > Although the NBTI shift may be demonstrated in a lab, there has never > been a case of a field failure for either the MGT, or dCM, due to NBTI. > It seems the condition is created by such a specific sequence of > temperatures, and static voltages, that unless you are unlucky enough to > duplicate, all the pmos shift together, and everything is just fine. > > NBTI starts out quick, then slows down. A bake without power restores > the levels a lot. Just turning things on and off, can mitigate any > issues. Very tricky stuff, but once understood, can be dealt with easily. > > NBTI is over thirty years old, and has been understood and dealt with by > the IO designers for a long time. What was a surprise is that MGT front > end design (and the DCM delay line) used thinner oxide devices in V4, > and didn't expect to see the shift. Foundry practices also helped tune > down the effects. > > This particular "melt-down" scenario is unrelated to NBTI. > > Common causes: shorts in the package/pcb/solder balls, over-temp of the > die (caused by inadequate heatsinking), large over voltage (on core, io, > or aux -- causes junction or gate breakdown, this may be power supply, > or ESD). > > Xilinx will issue a RMA (return mechandise authorization) and try to > find the cause of failure. However, this is not taken lightly, we > request that the customer removes the device using very specific > methods, so that we can establish what caused the failure (often > customers remove the device, destroying it in the process). > > A RMA is also something that takes time, and just one failure is not > considered a reason to go to all the trouble. > > Any device returned without authorization is not accepted. > > Austin Austin; Just out of curiousity, what is "NBTI" ? -Dave Pollum
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