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
Is the hardware API for "Xilinx Parallel Cable IV Model DLC7" published or does one have to figure that out by traditional engineering methods ..? (I want to know how to talk to the programmer cable by setting bits at port 0x378..)Article: 125926
The point is current spreading. Because they aren't intended for handling large forward currents, their junctions aren't designed to handle the thermal effects. Like an SCR's dI/dt rating, local heating can cause failure not expected for that current level. Tim -- Deep Fryer: A very philosophical monk. Website @ http://webpages.charter.net/dawill/tmoranwms "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:kh37j3lf5dcvpidvm7rl1403mb56ik05og@4ax.com... > >The diode circuit cannot be designed correctly (because it is being > >operated outside its specifications). > > What a bizarre thing to say. I'm an electrical engineer, and I do > stuff like this all the time. The behavior of forward-biased PN > junctions is fairly well known by now. And as Austin pointed out, the > actual operating range of Vccaux is huge. > > > > >If you are saying it is easier to "get it working" for a diode circuit > >than an LDO, you may be correct, under the right conditions (which > >generally disappear the moment the product is shipped). > > > >As mentioned earlier, continuously forward biasing a diode designed to > >operate reverse-biased may cause long term problems. > > Why would it do that? What would be the failure mechanism? What would > be the failure mode? > > Incidentally, zeners are use in the forward direction all the time, > like in bidirectional clippers and transzorbs. > > John > >Article: 125927
On Thu, 8 Nov 2007 23:14:35 -0600, "Tim Williams" <tmoranwms@gmail.com> wrote: >The point is current spreading. Because they aren't intended for handling >large forward currents, their junctions aren't designed to handle the >thermal effects. Like an SCR's dI/dt rating, local heating can cause >failure not expected for that current level. > >Tim I'm not all that concerned about dissipating 40 milliwatts in a 1-watt zener. JohnArticle: 125928
Maybe Xilinx Parallel Cable IV is backwards compatible with Paralllel Cable III ..?? which is supported by xilprg-0.5 it seems.Article: 125929
Hi all, I'm evaluating the MANIK mircoprocess from niktech (www.niktech.com). Following the GettingStarteedGuide, the first two examples (banner and ttest) can run happily. But I meet some problem when I compile the LwIP port for MANIK. I downloaded the code from the website and extract it to harddisk, them make. Here's the error messages: $ make Makefile:90: .depend: No such file or directory Makefile:98: *** multiple target patterns. Stop. Any suggestions? Thank you. JJArticle: 125930
On 8 Nov., 17:36, austin <aus...@xilinx.com> wrote: > JJ, > > You do not need to protect against momentary shorts to ground, or Vcco > (as long as you are within our abs max limits -- which you may well be > for a LVCMOS 23.5V 12 mA output as mentioned in the previous post). > > What will KILL any CMOS part, is a momentary short to a negative > voltage, which causes currents in excess of 200 mA to flow (in telecom, > with -48 battery everywhere, this is a real concern, as it is instant > death to short to -48V!!!!). > > Next, Xilinx abs max specs are perhaps different from some of our > competition: they are the limits at which there is no damage, or > reliability concerns (ie at these extremes, less than 0.1% of the parts > will fail after 20 years under these conditions). > > Often, manufacturers use the "abs max" as where the damage exceeds the > 0.1%/year at end of life, as it looks so much better (it makes their > parts appear more robust, when they are not that robust at all -- we all > use a standard foundry process, and all use similar design rules, so we > all have really the similar behavior when it comes to overstress, > reliability and failure). > > TANSTAFL > > Austin @Austin The problem is that the shorts may not be momentary. @John_H | | (FPGA) pin A |--------->| pin B (DUT) | | | | The shorts cases on the Device-under-Test(DUT) are: 1) pin B is shorted to GND 2) pin B is shorted to VCC If pin B on the DUT is an input pin, and I try to measure the state of that pin, the FPGA will read it unexactly as either high or low, since pin B is floating. If I enabled a pull-up resistor on pin A on the FPGA, I can check if pin B is shorted to GND, but If pin B is shorted to VCC, I wont know if its because of the pull-up resistor on the FPGA pin or because of an error. Please correct me if I am wrong. So IMHO, an effective solution is a series resistor. But since the fastest signals I will be getting through the FPGA is 100 MHz, I don't know if this is ok or not. I checked the IBIS model, there one can find the rise and fall time with a 50Ohm resistor, but I want the data for 100 Ohm. JJArticle: 125931
jidan1@hotmail.com wrote: > On 8 Nov., 17:36, austin <aus...@xilinx.com> wrote: > >>JJ, >> >>You do not need to protect against momentary shorts to ground, or Vcco >>(as long as you are within our abs max limits -- which you may well be >>for a LVCMOS 23.5V 12 mA output as mentioned in the previous post). >> >>What will KILL any CMOS part, is a momentary short to a negative >>voltage, which causes currents in excess of 200 mA to flow (in telecom, >>with -48 battery everywhere, this is a real concern, as it is instant >>death to short to -48V!!!!). >> >>Next, Xilinx abs max specs are perhaps different from some of our >>competition: they are the limits at which there is no damage, or >>reliability concerns (ie at these extremes, less than 0.1% of the parts >>will fail after 20 years under these conditions). >> >>Often, manufacturers use the "abs max" as where the damage exceeds the >>0.1%/year at end of life, as it looks so much better (it makes their >>parts appear more robust, when they are not that robust at all -- we all >>use a standard foundry process, and all use similar design rules, so we >>all have really the similar behavior when it comes to overstress, >>reliability and failure). >> >>TANSTAFL >> >>Austin > > > > @Austin > > The problem is that the shorts may not be momentary. > > > @John_H > > > | | > (FPGA) pin A |--------->| pin B (DUT) > | | > | | > > > The shorts cases on the Device-under-Test(DUT) are: > > 1) pin B is shorted to GND > 2) pin B is shorted to VCC > > > > If pin B on the DUT is an input pin, and I try to measure the state of > that pin, the FPGA will read it unexactly as either high or low, since > pin B is floating. > If I enabled a pull-up resistor on pin A on the FPGA, I can check if > pin B is shorted to GND, but If pin B is shorted to VCC, I wont know > if its because of the pull-up resistor on the FPGA pin or because of > an error. Please correct me if I am wrong. > > So IMHO, an effective solution is a series resistor. But since the > fastest signals I will be getting through the FPGA is 100 MHz, I don't > know if this is ok or not. I checked the IBIS model, there one can > find the rise and fall time with a 50Ohm resistor, but I want the data > for 100 Ohm. > > JJ Couple of solutions: Look at universal programmers They have parallel R (~1K) and small Cap (20-100pF region), so the edges are fast, but a stuck pin causes little grief. That also protects against DC drive outside the rails. Or you can add drive-check logic inside the FPGA, and read-back to check if the Driven level, is ever <> Pin level, for some defined time limit. If it is, you remoe the drive, and either flag it, or go into a power-save hiccup mode (see SMPS) -jgArticle: 125932
On 9 Nov., 06:09, kgll...@yahoo.com wrote: > Is the hardware API for "Xilinx Parallel Cable IV Model DLC7" > published or does one have to figure that out by traditional > engineering methods ..? > (I want to know how to talk to the programmer cable by setting bits at > port 0x378..) it is SUPER SECRET :( thats also the reason there are no 3rd party drivers thats the reason why it works so bad - on most cases the Cable IV works in Cable III fallback mode because of SUPERS**** windriver stuff that just failes the jedec file can however be readback, and i have jedec to vhdl convertert that converts 98% correctly back to vhdl but have had no time to fully RE the protocol if somebody is interested i can release the jed2vhdl converter with source codes, after little tweaking it should be able to produce VHDL that can be compiled back to working cable IV CPLD AnttiArticle: 125933
hello all, i would like to ask if you can give me a hint on this problem "ERROR:MDT - Ip ppc405 2.00.a is marked OBSOLETE" in edk6.2 version. thank you all:)Article: 125934
>The point is current spreading. Because they aren't intended for handling >large forward currents, their junctions aren't designed to handle the >thermal effects. Like an SCR's dI/dt rating, local heating can cause >failure not expected for that current level. Do you have a serious reference for this?Article: 125935
On Nov 9, 12:45 am, Bryan <bryan.fletc...@avnet.com> wrote: > The documentation for the P160 Comm 3 is still posted on the Avnet DRC > (www.em.avnet.com/drc), but the module is not for sale anymore. You > could try checking with your Avnet FAE or try finding a used one > somewhere. > > The P160 Comm 2 is still available, but it has a PHY rather than MAC > +PHY. > > Another alternative (but different hardware), is the Spartan-3 Mini- > Module. This has the same MAC+PHY as the P160 Comm 3. > > http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D25724%2... > > Bryan > > Sean Durkin wrote: > > ratemonotonic wrote: > > > Oh no ! I Have done a preliminary system design with the assumption > > > that a addon ethernet MAC/PHY Chip like P160 comms 3 module will be > > > available, for my memec Spartan 3 LC devlopment kit. Is there any way > > > out of this dilemma? > > When I asked my FAE about a year ago, I got the following response: > > > Re: XILINX MEMEC Boards Future: > > We have developed a new expansion standard called EXP. All new boards > > will use this format, and AvBus and P160/P240 will go away. We have > > created a EXP-to-P160 adaptor to allow P160 modules to connect to the > > new EXP boards. You can see more info on EXP atwww.em.avnet.com/exp > > > HTH, > > Sean > > > -- > > My email address is only valid until the end of the month. > > Try figuring out what the address is going to be after that... Hi Brayan , Yes it looks good. I thinks I will buy this. BR Rate.Article: 125936
jidan1@hotmail.com wrote: > > @Austin > > The problem is that the shorts may not be momentary. > > > @John_H > > > | | > (FPGA) pin A |--------->| pin B (DUT) > | | > | | > > > The shorts cases on the Device-under-Test(DUT) are: > > 1) pin B is shorted to GND > 2) pin B is shorted to VCC > > > > If pin B on the DUT is an input pin, and I try to measure the state of > that pin, the FPGA will read it unexactly as either high or low, since > pin B is floating. > If I enabled a pull-up resistor on pin A on the FPGA, I can check if > pin B is shorted to GND, but If pin B is shorted to VCC, I wont know > if its because of the pull-up resistor on the FPGA pin or because of > an error. Please correct me if I am wrong. > > So IMHO, an effective solution is a series resistor. But since the > fastest signals I will be getting through the FPGA is 100 MHz, I don't > know if this is ok or not. I checked the IBIS model, there one can > find the rise and fall time with a 50Ohm resistor, but I want the data > for 100 Ohm. > > JJ If your DUT is shorted to ground (pin B) and you only ever drive ground, there's not a problem. If the pin is shorted to VCC and you never drive anything but VCC, there's not a problem. If the pin is shorted to another pin and the two outputs driving those pins are always the same state, there's not a problem. If you drive an output that doesn't quickly settle to its expected logic state, you have a problem and can tristate that signal and raise a flag with no damage to the FPGA and no compromise on the communication speed or signal fidelity. Series resistors will also work but will not flag the customer that there's a problem with the DUT. All that having been said, if your DUT is an unterminated signal with a single load (rather than a daisy-chain of signals) you may do better with 33 ohm to 50 ohm series resistors depending on the board trace impedances. The source termination will drive the signal to about half the expected logic level until the open is detected on the other end of the transmission line. When the reflection from the open reflects back, rather than the current driving back into the output because of a reflected over-voltage, the reflected voltage will be correct and the output simply stop driving. For these terminations, it's often best to be smaller than the characteristic impedance because the drive has an added effective impedance; the combination is what ideally matches the transmission line impedance. - John_HArticle: 125937
>
> If your MCU is running much slower than the FPGA, you can use the
> FPGA's internal clock to run the synchronous FIFO, and a little
> state logic to generate the necessary (single cycle) pulses for
> read and write from the MCU interface signals.
In this case, logic is simply an edge detect.
ie.
reg read_level_q;
wire fifo_read_trailing_edge_det = ~read_level & read_level_q;
always @ (posedge clk)
begin
read_level_q <= read_level;
end
--
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.
Colorado Based Xilinx Consultant
email : jretta@rtc-inc.com
web : www.rtc-inc.com
Article: 125938Hi there, We just received EDK 9.2 but there seems to be an error in the install. I tried to install it and got the error message "F:\idata\drop28.zip.xz error in zipfile". The installer continued after this message, with the percentage progress bar continuing to rise, but at some point afterwards the windows closes and leaves me with a half-installed EDK install. I took a screenshot of the error message here: http://www.doc.ic.ac.uk/~pgp/edk9.2error.png Has anyone had a similar problem? Is it just a corrupt file on the install medium? Phil PS I would have opened a WebCase rather than reporting it here, but unfortunately it seems students aren't allowed WebCase access. -- Philip Potter pgp <at> doc.ic.ac.ukArticle: 125939
Anyone ever seen the contents of an FPGA "rom" (made up of several Stratix M4k rams with one read only port) corrupted? I have a design where the 80 mhz system clock is coming via the sample clock in-out path of a high performance ADC from an external low phase noise generator. If the clock glitches, cuts out, etc, the contents of some, but not all, of my FIR coefficient ROMs get scrambled. The read ports of these ROMs are run from this clock, but it shouldn't be possible to write to them. I also have a RAM that is writeable, and it similarly gets scrambled. I don't really want to use the clock PLLs, since my output registers need to be synchronized to the low phase noise source, which an FPGA PLL is not. I did some preliminary experiments with clocking most of the logic from a PLL and keeping only the input and output registers on the raw clock input, but I don't like working around a problem that in my opinion really shouldn't be happening. Any ideas why clock glitches could corrupt the ROMs? Only theory I can come up with is that maybe a bunch of faster than usual edges kerchunk all the logic, overtaxing the instantaneous power supply. Anyone seen something similar?Article: 125940
On 9 Nov, 09:58, xenix <last...@gmail.com> wrote: > hello all, > i would like to ask if you can give me a hint on this problem > "ERROR:MDT - Ip ppc405 2.00.a is marked OBSOLETE" in edk6.2 version. > > thank you all:) My guess is that version of the PPC core is obsolete.Article: 125941
On Nov 8, 4:42 pm, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Thu, 08 Nov 2007 14:01:47 -0800, Andy <jonesa...@comcast.net> > >The diode circuit cannot be designed correctly (because it is being > >operated outside its specifications). > > What a bizarre thing to say. I'm an electrical engineer, and I do > stuff like this all the time. The behavior of forward-biased PN > junctions is fairly well known by now. You have a degree in Electrical Engineering. So do I. When you design electronics that has to work right every time or the wrong people will die, you learn to do it right. The forward biased behavior of PN junctions designed to be operated primarily (albeit not exclusively) in the negative biased mode is not nearly so simple. I'm not an expert on forward biased zener diodes, and I wouldn't use it that way unless I was. Apparently, from other posts on this, there are potential problems that you and I are not fully aware of. I won't design a product that way. I may design an experiment that way, but I will specify additional analysis, screening, and source control measures to ensure that, once proven to be effective over the entire operating range, a product will continue to operate correctly over its entire range of operating conditions, over the duration of its production and useful life. Anything less is hacking, not engineering. And the cost of those additional measures nearly always exceeds the cost of doing it right in the first place. AndyArticle: 125942
On Fri, 09 Nov 2007 08:17:00 -0800, Andy <jonesandy@comcast.net> wrote: >On Nov 8, 4:42 pm, John Larkin ><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >> On Thu, 08 Nov 2007 14:01:47 -0800, Andy <jonesa...@comcast.net> >> >The diode circuit cannot be designed correctly (because it is being >> >operated outside its specifications). >> >> What a bizarre thing to say. I'm an electrical engineer, and I do >> stuff like this all the time. The behavior of forward-biased PN >> junctions is fairly well known by now. > >You have a degree in Electrical Engineering. So do I. > >When you design electronics that has to work right every time or the >wrong people will die, you learn to do it right. > >The forward biased behavior of PN junctions designed to be operated >primarily (albeit not exclusively) in the negative biased mode is not >nearly so simple. I'm not an expert on forward biased zener diodes, >and I wouldn't use it that way unless I was. Apparently, from other >posts on this, there are potential problems that you and I are not >fully aware of. I won't design a product that way. I may design an >experiment that way, but I will specify additional analysis, >screening, and source control measures to ensure that, once proven to >be effective over the entire operating range, a product will continue >to operate correctly over its entire range of operating conditions, >over the duration of its production and useful life. Anything less is >hacking, not engineering. And the cost of those additional measures >nearly always exceeds the cost of doing it right in the first place. > >Andy > I didn't design the diode in originally; it was a hack to fix a problem on these boards. People who are "not an expert on forward biased zener diodes" are conjecturing problems without suggesting what they might actually be, except prissy comments about "not the intended use", as if the silicon cares. All rectifier diodes are zener diodes, and they seem to work in the forward direction for a long time. The only thing remotely like this that I've ever heard of is the fact that longterm zenering of a transistor b-e junction can reduce beta. I've never heard that forward biasing a diode can damage its forward-bias performance. [1] Hell, I'll probably use the diode next rev, too. I'm starting to like it. John [1] except for GaAs tunnel diodes.Article: 125943
There is a timing diagram comparison between using DCM and not using DCM in http://www.xilinx.com/products/design_resources/highspeed_design/hsd_clockmanagement.htm I don't know what the 'c2p' and 'c2o' mean here. The result I found is 'c2p' stands for Military DC-DC Power Supplies and 'c2o' is 1.8, 2.5, 3.3, 5.0 volt CMOS Oscillator. It looks not good. Does anybody know the meaning of them exactly good for explaining in the diagram. Many thanks.Article: 125944
From "Cyclone II Device Handbook", volume 1, (Altera Corporation, Februrary 2007), page 2-28: "Violating the setup or hold time on the memory block address registers could corrupt memory contents. This applies to both read and write operations". Probably you should check the Stratix handbook for your case. >Anyone ever seen the contents of an FPGA "rom" (made up of several >Stratix M4k rams with one read only port) corrupted? > >I have a design where the 80 mhz system clock is coming via the sample >clock in-out path of a high performance ADC from an external low phase >noise generator. If the clock glitches, cuts out, etc, the contents >of some, but not all, of my FIR coefficient ROMs get scrambled. > >The read ports of these ROMs are run from this clock, but it shouldn't >be possible to write to them. I also have a RAM that is writeable, >and it similarly gets scrambled. > >I don't really want to use the clock PLLs, since my output registers >need to be synchronized to the low phase noise source, which an FPGA >PLL is not. I did some preliminary experiments with clocking most of >the logic from a PLL and keeping only the input and output registers >on the raw clock input, but I don't like working around a problem that >in my opinion really shouldn't be happening. > >Any ideas why clock glitches could corrupt the ROMs? Only theory I >can come up with is that maybe a bunch of faster than usual edges >kerchunk all the logic, overtaxing the instantaneous power supply. > >Anyone seen something similar?Article: 125945
"ZHI" <threeinchnail@gmail.com> wrote in message news:1194637371.064656.155460@50g2000hsm.googlegroups.com... > There is a timing diagram comparison between using DCM and not using > DCM in > http://www.xilinx.com/products/design_resources/highspeed_design/hsd_clockmanagement.htm > > I don't know what the 'c2p' and 'c2o' mean here. The result I found > is 'c2p' stands for Military DC-DC Power Supplies and 'c2o' is 1.8, > 2.5, 3.3, 5.0 volt CMOS Oscillator. It looks not good. Does anybody > know the meaning of them exactly good for explaining in the diagram. > Many thanks. Interpret them as "Clock to Pad" where the reference is to the external clock and "Clock to Output" where the reference is to the internal clock. This is not an "industry standard" notation of any kind because, frankly, there are no industry standards for this kind of stuff. The author probably took a little more liberty in the diagrams than most would. - John_HArticle: 125946
Is there a bit slip function in the V5 GTP transmitter? Normaly this function is supported in the deserializer devices for alignment purposes. Thanks. CPArticle: 125947
On Nov 9, 2:58 pm, MikeShepherd...@btinternet.com wrote: > From "Cyclone II Device Handbook", volume 1, (Altera Corporation, > Februrary 2007), page 2-28: > > "Violating the setup or hold time on the memory block address > registers could corrupt memory contents. This applies to both > read and write operations". Interesting idea, as one discovery I made is that if I hold my logic in user reset while abusing the clock, it seems to survive, provided I bring it out of reset only under conditions of a clean clock. Reset does nothing to the memory itself, but it does mean that the address register isn't changing. Still, even if an explanation, this seems like it would be pretty spotty behavior for a "ROM" !Article: 125948
On Nov 8, 8:41 pm, raull...@hotmail.com wrote: > On Nov 7, 10:02 pm, John_H <newsgr...@johnhandwork.com> wrote: > > > raull...@hotmail.com wrote: > > > i would like to ask how can i capture the FPGA master clock signal in > > > the oscilloscope? Bcos in the data sheet, it indicates that the master > > > clock is located at pin N9 which is not accessible externally. please > > > help. thanks a million > > > Are you *sure* this signal is not externally accessible? Typically the > > BGA package has a matrix of pads and vias. The via for the clock signal > > should be exposed on the back of the board, ready for a steady hand to > > probe the clock right there "at" the package ball. > > i am using the XEM3010 board. really have no idea how to tap the > signal. please help.. Is there a schematic available in the XEM3010 documentation? If so, it should be possible to find another pin somewhere else on the board where the same clock signal can be probed with your oscilloscope. John LeVieuxArticle: 125949
<cs_posting@hotmail.com> wrote in message news:1194640373.390273.6770@19g2000hsx.googlegroups.com... > On Nov 9, 2:58 pm, MikeShepherd...@btinternet.com wrote: >> From "Cyclone II Device Handbook", volume 1, (Altera Corporation, >> Februrary 2007), page 2-28: >> >> "Violating the setup or hold time on the memory block address >> registers could corrupt memory contents. This applies to both >> read and write operations". > > > Still, even if an explanation, this seems like it would be pretty > spotty behavior for a "ROM" ! > FYI, some of Xilinx's RAMs have a similar (maybe the same?) problem. http://www.xilinx.com/support/answers/21870.htm HTH., Syms.
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