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
How can we possibly help you, when we know nothing about your design? Peter AlfkeArticle: 101401
"Hans" <hans64@ht-lab.com> schrieb im Newsbeitrag news:h_%4g.4329$ca3.3138@newsfe5-gui.ntli.net... > Hi Antti, > > What about morse code to give the status? > > I should have some code in VHDL which I will dig out and send to you, > > Regards, > Hans > www.ht-lab.com Hi Hans, yes VHDL based morse message could be added, I think I had something some while ago, but not sure if I can dig that out, so if you find I will look it. I have been actve on short-waves ages ago so Morse of course popped up in my mind too, well its of course easier to implement with some small soft-core processor, but plain HDL version could also be a nice example AnttiArticle: 101402
.- -. - - .- .-- . .-. . -.-- --- ..- .- .... .- -- ..--.. .- ..- -.... ...- ..-Article: 101403
Responses embedded - this is to underscore why I don't believe the information has been adequately digested, not because I feel an arguement is necessary. Trivial aspects of the design are not properly documented - that's been admitted - but the corrections have not been brought to our attention. So - trivially - what *did* I need to know about the JTAG interface that would have saved about 50 engineering hours and a change to a board that would have gone through a spin anyway? I'd sure like to know in case I end up designing with that part instead of the two XC3S1600Es on an upcoming board. Peter Alfke wrote: > John, this is analog territory, and there is NOT just ONE right answer. This could be digital territory but the analog aspects - pullups that are unaffected by HSWAP_EN - are forced upon the designers for pins - such as the JTAG - that no engineer should suspect would be pulled up by the silicon. > Obviously, a short circuit will always work, if you never need the pin > for any other purpose. > But we will not force you to do that, since you may have reasons not > to like it. It's a free country! > There is no mystery here, the purpose is only to establish a High > logic level. Nothing more, nothing less. > Obviously, a built-in pull-up resistor will establish a High logic > level, but it might be sensitive to crosstalk coming from your > pc-board.. And the Spartan3 devices have an explicitly low pullup impedance that should be virtually immune to any crosstalk that's applied to an unconnected pin. I'd expect the antenna of connecting a 10 kohm resistor to the internal 3 kohm pullup would introduce more noise than leaving the pin unconnected. > Obviously, any external resistor reduces the pull-up impedance, and > improves the situation. > Obviously an external pull-down resistor must be low enough in value to > overcome the internal pull-up resistance. > > And I still favor a multimeter for getting a grip on fundamentals. A multimeter is nice if a board that *isn't* strapped to VCC or GND is readily available - not usually the case when someone's designing their first board with this series of devices - but it still provides only an order of magnitude idea of what's happening on the pin. Tolerances on pullup and pulldown currents don't need to be tight so they aren't. I *will not* design a production board that relies on measurements to determine acceptable operation. The silicon *must* be tested to analog parameters that will guarantee operation in the board environment I design to. > I am all for clear documentation, but it never hurts to keep the > engineering mind alive. An engineering mind is of little use when you have to submit to a design review with other engineers - some of which haven't designed with the device or know the documentation as thoroughly as someone who has - and must have documentation to support any action items produced from the review. > Compared to multi-gigabit receiver issues, this mode-pin level debate > is really a trivial subject. > > Peter Alfke Trivial subjects deserve trivial answers. There have been no answers that I have seen in these threads. _____ Will the mode pins which appear to always have external pullups independent of the HWSWAP_EN pin behave fine when no external resistors are connected? Will the ~3kohm equivalent pullup impedances in unconnected pins work *just as well* or better than an external 4.7kohm pullup resistor to an imaginary mode pin with no internal pullup? If the answer is "sure, no problem" where do we assure the fellow engineers that the pins will behave properly on power up (e.g., once the POR thresholds are passed, will those internal pullups have the full logic level established with internal pullups)? Is there a design issue such that POR from external pullups of nominal impedance willnot produce valid operation? Where could I possibly devine what the minimum pulldown resistor is to establish guaranteed behavior allowing an external jumper to change the mode pins? These are trivial issues. With no documented answers. The last request from rickman was specifically - quoted in full: rickman wrote: > People here are driving me crazy insisting that the Xilinx factory has > told them that you *MUST* tie the mode pins to either Vaux or GND. > After finding all the info in the data sheet and talking with support, > it looks pretty clear to me that the S3 parts have a very stiff > internal pull up and there is no need for an external pull up of any > kind, resistor or direct connection to Vaux. > > Am I misunderstanding? Why did the factory tell us before that the > mode pins *MUST* be tied to Vaux? Did we misunderstand what they were > saying? > > I promise this is the last time I will ask about this. I am totally > sick of going around this loop with everyone here. Do you believe that the trivial answer *has* been fully illustrated by Steve Knapp or others in these threads? There isn't a great desire to spend time and attention to trivial matters when there are problems like Multi-Gigabit transceivers out there. If we lose the trivial details, we lose the ability to design for error free production because of trivial misunderstandings. All ricman wants is to get the fellow engineers off his back on a trivial issue. All I want is an understanding of how the pins behave that I connect for "trivial" functionality such as the JTAG pins that I *could not configure* to operate as part of a chain - I had to give the Spartan3 its own chain. The problems I had are probably trivial but I was unable to work past them without extreme measures.Article: 101404
"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag news:e32s8f$cvm2@xco-news.xilinx.com... > .- -. - - .- > > .-- . .-. . -.-- --- ..- .- .... .- -- ..--.. > > .- ..- -.... ...- ..- > ROTFL ! i did think f**** windows has trouble refreshing screen, so I closed and opened this email many times. in the hope it would display the fonts properly - morse code !!! A N T T A W E R E Y O U A H A M ? A U 6 V U uh? I probably need morse-classes to decode the message properly :) AnttiArticle: 101405
"Ben Twijnstra" <btwijnstra@gmail.com> schrieb im Newsbeitrag news:4e4cb$4454abc7$d52e23a9$4555@news.chello.nl... > Hans wrote: > >> Hi Antti, >> >> What about morse code to give the status? >> >> I should have some code in VHDL which I will dig out and send to you, >> > > Best to then blink the Morse dots using PWM at 1KHz and 50% duty cycle so > that you can also hear it with a solar cell and a piezo earpiece ;-) > > Ben HAHA - I was going to reply that the LED is SMD 0603 so connecting beeper in parallel would not make sense, but then hum solar cell !! hum, interesting would it actually work? I bet not the solar cell possible would not deliver AC or would it? I am almost tempted to test! well the LED on board will be possible cheapest one available (around 0.01 USD from HK) so it will not have many mcd, but the LED + solar cell idea is something that could be even used for some weird application. AnttiArticle: 101406
Peter Alfke wrote: > Jim, please give us the benefit of the doubt, that we are not totally > stupid. > The mode pins are of interest at the very beginning of the > configuration process. > That's obviously when the pull-ups are active. > I do not know when they are being de-activated, but trust us that they > are active when it matters. But is that if externally strapped to ground as someone at the factory appears to have informed rickman's group or unconnected such that the internal pullups guarantee operation all the time? > We have 22 years experience in this technology, and have shipped many > hundreds of millions of FPGAs... > But you are right, there is always an opportunity for better > documentation. > Remember: This whole lengthy discussion never mentioned a technical > problem or malfunction, only a diversity of suggestions, all of them > correct. The discussion has a technical problem as the source. His steps may be slightly different but in my ISO9000 dictated compliance from years ago, if a design review produces an action item that says "check if the mode pins must be strapped to the rails directly because I saw that done on a Xilinx official application note" then that item must be followed up with a documented response providing evidence to address the original concern. This technical problem - guaranteeing the design will operate as expected to the satisfaction of picky reviewers - cannot be addressed with the information at hand either through the data sheets, the FAE (incorrect info - we're all human), or through this forum. > > Peter Alfke, Xilinx, from home - John Handwork Exclusively Xilinx for 8 years nowArticle: 101407
Aren't you and Xilinx developing a new line of FPGA's called "The Crystal Ball Series"? Parallel psychic processing that transcends the sphere of phsyical science or knowledge. Sorry, I couldn't resist. "Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1146413978.650624.70750@i39g2000cwa.googlegroups.com... > How can we possibly help you, when we know nothing about your design? > Peter Alfke >Article: 101408
"Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag news:44548f48@clear.net.nz... > Antti Lukats wrote: > >> Hi all >> >> I am looking for ideas for: "FPGA Single LED Demos", The requirements for >> the demo Application are following: >> >> * Display visible 'sign of live' or 'self-test passed' message >> * Impemented in FPGA Vendor neutral HDL >> * <= 3000 LUT >> * <= 4KB of Block RAM >> * uncalibrated (+-50%) high frequency oscillator >> * 1 user LED for display >> >> The Demo application should have some sort of LED visible 'message' to >> indicate the demo is working or has passed internal self test code. There >> is no user interface byeound one single LED. > Most obvious is to extend to a BiColour LED, Driven from 2 pins, so > that you can generate : Pure RED, Modulated RED (OE), Pure GREEN, > Modulated GREEN (OE) and Colour Modulated (PWM %R/100-% G) > Control lines are : R, R.oe, G, G.oe > dual color SMD led costs 10 times as much as single color and the layout isnt so standard and I have some pre-series PCBs with only one LED already. Sure dual color LED would have more possibilities for visual effects > Then at eye-ball rates, you can signal something over 4 states, without > needing long dividers. > > [Well, yes, this is only partially vendor neutral: it works on all those > vendors who actually gave this some thought, and installed a BiColour > LED ] > > My preferred modulation is PDM (Rate Multiplier), rather than PWM : PDM > uses the least resource in CPLDs, and filters better in DAC applications. > could you elaborate on this? I had delta-sigma DAC already on my list that is pulse density modulation - but you are referring to something else? > Also not on your list, is a RC5 / manchester Encoded LED modulate. > Target the std IR-Remote Receivers, perhaps with an IR led in Parallel > if the RED energy is too low to activate a NearBy - StdIR RX unit. > > That allows actual BIT serial (status flags) info to be sent, into a > simple receiver. > > One-Wire encoding is another way to send Freq tolerant information, > in an easily decoded manner. > Actually one-wire comm requires known frequency reference better than I can count for, also in my requirements was no other interface (than LED) >> Best ideas can be rewarded with an FPGA evaluation board (with your idea >> pre-programmed). Suggestions a-la "soft-core cpu acme/xyz" will not >> count. > > -jg > I was possible giving not enough information at first place - the module in question has actually 3 interfaces with 6+6+4 (shared with JTAG pins in parallel) I/O's one of them can be used for block transfers to host with up to 6MByte/S However any communication with host would require some software on the host what may not exist for the host platform, so I was looking for demos that can be 'tested' for simple 'it blinks, ít works' in the case we assume there host communication is unavailable - similarly any demos requirying additional hardware ae beyound the scope, dual color, tri-color led buzzer, IR tranceiver are all things that could be used, - with extra add-on modules. I was more looking for more ideas to demonstrate things that an FPGA can do, it could be some algorithm that is processed once or in a look and if the self check result is ok then blink a led. Just to have people a way to 'seeing is beliving' want to test this or that, download this, when LED blinks then it is signal that this or that works - in real hardware. AnttiArticle: 101409
<harikris@gmail.com> schrieb im Newsbeitrag news:1146413671.605299.107260@v46g2000cwv.googlegroups.com... > Hi, > > I am targeting the design for XC2C512 coolrunner device. That's the > biggest device i could find. Are you aware of any larger CPLD device? > I have a dual-edge triggered clock i.e i have no other CPLD choice > other than the coolrunner series. > > I find that i am falling short of a dozen macrocell counts. The > fitter report says it needs 524 macrocells and i have 512 macrocells > available to me :-( > > I have tried to optimize the design to my best possible knowledge (and > my knowledge is not that profound). > > Can anybody here advise me on how to squeeze the design a LITTLE BIT > more > to make it fit into the XC2C512 device? > > Thanks. > there are almost no generic rules, but specially for PLDs the design for PLD optimization can yield in huge macrocell reduction. if your current count is 524, then I would say with 99.9% that the desing can be made fit into 512 unless you have already spent over one man-month in PLD specific optimization to get the MC count down to 524. the easiest way to find some resources is to find some block that are never active at same time and use 1 extra MC to flag for resource sharing as example if you need counter and shift register but not at the same time then almost all MCs uses in counter and shift register could be shared. besides that there are pretty many things for PLD that can influence the design fit, but again no golden rule for you, its all design specific and based on general 'it doesnt fit' there is little help that could be given to you AnttiArticle: 101410
maxascent wrote: > I may have overlooked something but I cant seem to find the dimensions of > the platform flash PROM in a FS48 package. I have the datasheet but it > appears not to be in it. Also had a look on the Xilinx website but again > no luck. Can someone point me to the right place? > > Cheers > > Jon Try this link to the package drawing. http://www.xilinx.com/bvdocs/packages/fs48.pdf -- Steve KnappArticle: 101411
Rob schrieb: > Aren't you and Xilinx developing a new line of FPGA's called "The Crystal > Ball Series"? Parallel psychic processing that transcends the sphere of > phsyical science or knowledge. How dare you write this in a newsgroup? I had to sign an NDA on that topic. Kolja SulimmaArticle: 101412
"Kolja Sulimma" <news@sulimma.de> schrieb im Newsbeitrag news:44550796$0$4514$9b4e6d93@newsread2.arcor-online.net... > Rob schrieb: >> Aren't you and Xilinx developing a new line of FPGA's called "The Crystal >> Ball Series"? Parallel psychic processing that transcends the sphere of >> phsyical science or knowledge. > > How dare you write this in a newsgroup? > I had to sign an NDA on that topic. > > Kolja Sulimma is there an April joke somewhere? 'Crystal Ball' !? AnttiArticle: 101413
Antti Lukats wrote: > "Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag >> Most obvious is to extend to a BiColour LED, Driven from 2 pins, so >>that you can generate : Pure RED, Modulated RED (OE), Pure GREEN, >>Modulated GREEN (OE) and Colour Modulated (PWM %R/100-% G) >>Control lines are : R, R.oe, G, G.oe >> > > dual color SMD led costs 10 times as much as single color and the layout > isnt so standard and I have some pre-series PCBs with only one LED > already. Sure dual color LED would have more possibilities for visual > effects But costs a tiny fraction of the PCB / FPGA price, which is what actually matters ? >> My preferred modulation is PDM (Rate Multiplier), rather than PWM : PDM >>uses the least resource in CPLDs, and filters better in DAC applications. >> > > could you elaborate on this? I had delta-sigma DAC already on my list > that is pulse density modulation - but you are referring to something else? It is probably the same thing, if your delta-sigma is PDM. I am used to delta-sigma having a feedback loop of some sort, so I avoid that term. The PDM we use is the same as the venerable Rate Multipliers ( 4089, 4527 IIRC) and they use one PT per resolution bit. PWM compares need two, unless hand-coded. >> Also not on your list, is a RC5 / manchester Encoded LED modulate. >>Target the std IR-Remote Receivers, perhaps with an IR led in Parallel >>if the RED energy is too low to activate a NearBy - StdIR RX unit. >> >> That allows actual BIT serial (status flags) info to be sent, into a >>simple receiver. >> >> One-Wire encoding is another way to send Freq tolerant information, >>in an easily decoded manner. >> > > Actually one-wire comm requires known frequency reference better than > I can count for, also in my requirements was no other interface (than LED) You would use optical pickup, so are outside the "Mk1 EyeBall", but the functions can be stacked on the LED. One wire systems are usually PWM coded, so autobaud ? > Just to have people a way to 'seeing is beliving' want to test > this or that, download this, when LED blinks then it is signal > that this or that works - in real hardware. Always a good idea. -jgArticle: 101414
harikris@gmail.com wrote: > Hi, > > I am targeting the design for XC2C512 coolrunner device. That's the > biggest device i could find. Are you aware of any larger CPLD device? There are plenty : Lattice MachXO, Altera MAX II are the 'new designs' arena, Lattice & Actel also have FLASH FPGAs, and lattice have older CPLD families that are > 512 MCells, but their price/ability point is probably not ideal these days. > I have a dual-edge triggered clock i.e i have no other CPLD choice > other than the coolrunner series. See other threads, on how to create Dual Edge using two single edge FF+XOR. Plus, you can always clock double, or use a PLL. > > I find that i am falling short of a dozen macrocell counts. The > fitter report says it needs 524 macrocells and i have 512 macrocells > available to me :-( > > I have tried to optimize the design to my best possible knowledge (and > my knowledge is not that profound). > > Can anybody here advise me on how to squeeze the design a LITTLE BIT > more to make it fit into the XC2C512 device? Scan thru the FIT RPT file, and look at your modules, for resource usage. Sometime it is easier to compile portions of the design, and paste those summaries, then scan them with your eye and a pencil, for ones that use more that their 'fair share' of resource. A small change in HDL coding can give a big change in resource. -jgArticle: 101415
I am working with an embedded MicroBlaze project that has multiple Xilinx cores and multiple custom IP cores. The FPGA hardware is used to interface to our comapanie's "parts". Some of the custom core functionality includes serial communications interfaces and special time-critical data interfaces. We have two "flavors" of parts that the FPGA hardware has to support. Each part outputs a reference clock that we want to use inside the FPGA. However, each part outputs a different clock frequency. I am working on reconciling the FPGA hardware in order to run both parts with the same FPGA build. The clock from the part is used to clock our custom IP modules. The timing of the modules is derived from those clocks and works out nicely. However, one of the part's clocks needs to be used at 1X fequency, the other at 2X. My first thought is to use the input clock from the part, which would be one of two different values, and route that to a DCM. Then I would use the 1X and the 2X output of that DCM. Both outputs would be fed to an OPB software controlled mux. I forgot to mention that we also have an on-board xtal that is currently used for ALL the clocking needs of the FPGA. We run it at one of the part's frequencies so it is fine. But a new part, with a new clock, is coming out that we have to support. So the one clock solution will not work for both. I am rambling... Anyways, I am thinking of using the xtal to feed a DCM that will derive a clock that will drive the MicroBlaze, the Xilinx OPB cores, and the above-mentioned clock switching mux. My concern is with driving the OPB clock inputs on different cores with two different clocks. Out cores would be driven by one of the two clocks selected from the mux. The xilinx OPB cores would be driven by the xtal DCM clock. Is it OK to do this? Do I have to consider clock domain issues when doing this? Thanks!Article: 101416
Peter- > Compared to multi-gigabit receiver issues, this mode-pin level debate > is really a trivial subject. I think that type of thinking shows a problem. Engineers can't use your devices if they a) can't trust your documentation, b) can't get a straight answer from Xilinx experts to augment the documentation in an official and formal manner that stands up to design review, and c) have to spend weeks messing around with configuration just to get the part up and running before they can even try advanced features. I would turn this around and say: if you can't handle basic configuration issues, then how can you be trusted to handle MGT issues? What happens when you next decide that inner workings of a BUFGMUX are "trivial"? I can't get a straight answer on that either. I always worried important Xilinx people were thinking like this. Please I hope it's not really the case. -JeffArticle: 101417
Antti Lukats wrote: > HAHA - I was going to reply that the LED is SMD 0603 so connecting beeper > in parallel would not make sense, but then hum solar cell !! > > hum, interesting would it actually work? I bet not the solar cell possible > would not deliver AC or would it? I am almost tempted to test! > > well the LED on board will be possible cheapest one available (around 0.01 > USD from HK) so it will not have many mcd, but the LED + solar cell idea > is something that could be even used for some weird application. Some twenty-five years ago I used to be able to 'hear' the brightness on the television by the volume of the 50Hz hum if I pointed a solar cell at the screen at close range (10-20cm). The solar cell was a cheap single-cell thingie bought at Tandy/Radio Shack, so if solar cell efficiency has made any sort of improvement in the last quarter-century, this might actually be viable. Best regards, BenArticle: 101418
Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote: > maxascent wrote: > > I may have overlooked something but I cant seem to find the dimensions of > > the platform flash PROM in a FS48 package. I have the datasheet but it > > appears not to be in it. Also had a look on the Xilinx website but again > > no luck. Can someone point me to the right place? > > > > Cheers > > > > Jon > > Try this link to the package drawing. > http://www.xilinx.com/bvdocs/packages/fs48.pdf > > -- Steve Knapp In another thread you asked for feedback on documentation. Not including packaging in the main datasheet is very bothersome. Almost everyone else in the chip industry puts packaging at the end of the part datasheet. Just my 2 cents GaborArticle: 101419
Let me repeat: If you want a mode pin to be interpreted as all High, you can do one of three things, and all are correct: 1. do nothing 2. use external pull-up of any value 3. strap to Vcc If you want a mode pin to be interpreted as Low, do one of two things: 1. strap to ground 2. use a resistor of 330 Ohm or lower to ground. The mode pins have an internal pull-up resistor during configuration. Once the FPGA has been powered up, and the configuration memory has been cleared, the INIT pin goes High, and this Low-to-High transition on INIT samples the levels on the mode pins. At any other time, (earlier or later) the levels on the mode pins are irrelevant to the FPGA configuration process, or to its operation. For people who prefer not to think, we can also be dictatorial: "You must strap mode pins to either Vcc or ground." It sure works 100% of the time, but it is not the only possible way. This has been described in many generations of Xilinx data books, ever since I was responsible for them in the late 'eighties and early 'nineties, and the behavior of the mode pins never changed in our 18-year history. Peter AlfkeArticle: 101420
Dear All, For my application, I'm using a Spartan-3 Starter Kit Board, with a microblaze microcontroller (uart, timer, bram, etc). I need the microcontroller to control a few digital lines connected to somme discrete logic on the outside of the board. As far as I can understand, and since those lines don't need to be fast, the easiest way is to hook them on the OPB via a GPIO module. My question is how to do that. I think I wave to create a custom OPB peripheral using the XPS wizard, and then edit the created VHD files, as it is donne for a "regular" IP, but in this case connecting the registers directly to signals, noting more, but i'm not sure. Is this correct? Can anyone direct me to a tutorial. Tank you very much jmarianoArticle: 101421
Hi Lukats/Jim, Thanks for the sugggestions. I will work on those lines. I have not spent nearly a day thus far to try fit the design and your comments seem to be encouraging. Thanks.Article: 101422
Using the EDK you can just add a GPIO module to your project and connect it how you want to. the module is parameterized so you can specify how many lines you need. After that, you have to use the Xilinx provided drivers to "talk" to the core via software. I assume you know C or C++. It is not my strong suit by any means. Someone else in my group does that part of the project! But I know from looking that there are functions you call to set the direction of the lines and to set bits high or low (in essence, making that GPIO line high or low). You access the core using the address generated by the EDK and software pointers (at least that is how we do it). Basically, you will read and write to the GPIO address to control the actual lines of the device, which will be added to your external port list and connected to your outside logic. I am sure that there is documentation in the EDK installation directory that will go in to this in detail. Since you mentioned you are using the UART, Timer, etc. I assume that you know the nitty gritty of the programming side. Hope that helps some!Article: 101423
On 30 Apr 2006 06:34:15 -0700, "rickman" <spamgoeshere4@yahoo.com> wrote: >John Larkin wrote: >> On 28 Apr 2006 11:30:00 -0700, "rickman" <spamgoeshere4@yahoo.com> >> wrote: >> >> >People here are driving me crazy insisting that the Xilinx factory has >> >told them that you *MUST* tie the mode pins to either Vaux or GND. >> >After finding all the info in the data sheet and talking with support, >> >it looks pretty clear to me that the S3 parts have a very stiff >> >internal pull up and there is no need for an external pull up of any >> >kind, resistor or direct connection to Vaux. >> > >> >Am I misunderstanding? Why did the factory tell us before that the >> >mode pins *MUST* be tied to Vaux? Did we misunderstand what they were >> >saying? >> > >> >I promise this is the last time I will ask about this. I am totally >> >sick of going around this loop with everyone here. >> >> >> We leave them open, slave serial. Works fine. > >At last, a clear, rational statement. Thanks. > >I can't say that solves my problem though. I have little doubt that >there is any issue to the pullups working if you just leave them open. >The fact that they are such a low resistance seems to me to make it a >near certainty that they will pull up properly if left open. > >This board is currenly ready to come out of layout with the only >remaining issues, SI on the data and address bus which we think is due >to an overly agressive TI IBIS model, it does not match the units we >can measure; and this stupid pullup resistor issue. > >There is little doubt in my mind that the stiff internal pullups make >an external pullup unnecessary. I spoke with the engineer who had >spoken with the Xilinx factory person and I had trouble finishing a >sentance without being interrupted. It is very likely that she >misunderstood what Xilinx was saying to her. I expect she was told >that the pull *down* resistors needed to be tied directly to GND and/or >the distinction between the pull ups and pull downs was not made. The >fact that the data sheet and app notes show direct connections to Vaux >and GND does not make the matter any more clear. > >Just to be very clear that the difference between a resistor pullup and >a direct connection is not splitting hairs, we have a current part on a >board that does not work correctly because of a similar issue. The pin >has three states for setting an I2C bus address; high, low and open. >Seems the part is having trouble distinguishing the difference between >high and open with most reistor values. That data sheet also did not >make it clear what value resistor was required as well as the level of >noise immunity on the input. > >That engineer is working a lot of unpaid overtime at the moment. I >prefer to get this ironed out before I am done with layout and can >still make a change if *required*. Well, the real issue is: who's in charge of the design? The point of engineering is (I theorize) not that you do what other people say, but that you think. And can't you demonstrate the pullup strength with a milliammeter? JohnArticle: 101424
On 24 Apr 2006 09:27:02 -0700, "rickman" <spamgoeshere4@yahoo.com>
wrote:
>I found this sentance to be especially unenlightening...
>
>"The Dedicated configuration pins (CCLK, DONE, PROG_B, M2, M1, M0,
>HSWAP_EN) and the JTAG pins (TDI, TMS, TCK, and TDO) always have a
>pull-up resistor to HSWAP_EN during configuration, regardless of the
>value on the HSWAP_EN pin."
It's stunning how bad IC documentation is, and not just Xilinx. The
use of the passive voice ("the enable input, when asserted..." Who
the hell pulls it high, or maybe low, me or the chip?) and the
persistant refusal to distinguish between levels and edges are two
especially annoying lapses. The guys who do mixed-level stuff, like
serial ADCs, are extra bad.
Who *writes* this stuff?
John
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