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
"maxascent" <maxascent@yahoo.co.uk> wrote in message news:T9CdncycrbbpP7bZRVn_vA@giganews.com... > Hi > > I need to layout a Virtex 2 Pro board using a 672 BGA package. Does anyone > have any tips for the placement of the bypass caps. I want to use 0603 > caps > and normal PTH vias. I can see that it might get a bit crowded trying to > position a lot of caps under the device near to the power pins with all > those vias. > > Cheers > > Jon Jon - The best thing you can do for yourself is to use solid power and ground planes in your board and place them as close together as possible. A dielectric thickness between PCB layers of 0.004" (4 mils) is mainstream these days. As rickman stated, the goal is to minimize the loop area/inductance between the BGA balls and the bypass cap. Keeping the places close together is far more important in achieving this than placing the caps close to the balls, which is often impossible. There is a wealth of literature available on this subject if you look around for it. Next, place the bypass caps for each voltage rail on the side of the board that is closest to the power/GND plane pair in your PCB stackup. Think loop area again. The vias from the cap to the planes form a loop, so the shorter the distance the better. Third, there are good and bad ways to mount bypass caps. Andy mentioned this. Xilinx shows the good and bad mounting methods in XAPP623. I highly recommend you read this app note. Going back to loop area, keeping the two vias from the cap to the planes close together lowers the loop area. Using multiple vias lowers is even more, but I don't recommend this because it clogs routing and pokes even more holes in your already Swiss-cheesed power and ground planes. Lastly, place the caps as close to the package as you can without destroying your routing channels. If you do everything above correctly then the distance from the BGA balls to the bypass caps is not that critical. Within a couple of inches is fine. If you research this topic you'll also see varying recommendations on how to achieve a flat PDS (power distribution system) impedance over as wide a frequency range as possible by using several different cap values. This complicates the process a little but research shows it actually works. I still get away with using 0.01uF 0402 caps as my general bypass, with a few larger value (e.g., 2.2uF or 4.7uF) scattered around. Typically one larger value be I/O bank, one for VCCAUX, and maybe a couple for VCCINT. Good luck! RobArticle: 99951
John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >On Tue, 28 Mar 2006 08:55:50 +1200, Jim Granville ><no.spam@designtools.co.nz> wrote: > >>John Larkin wrote: >> >>> Some ideas: >>> >>> 1. Use the DCM to multiply the clock by, say, 8. Run the 16 MHz clock >>> as data through a dual-rank d-flop resynchronizer, clocked at 128 MHz >>> maybe, and use the second flop's output as the new clock source. A >>> Xilinx fae claims this won't work. As far as we can interpret his >>> English, the DCM is not a true PLL (ok, then what is it?) and will >>> propagate the glitches, too. He claims there *is* no solution inside >>> the chip. >>> >>> 2. Run the clock in as a regular logic pin. That drives a delay chain, >>> a string of buffers, maybe 4 or 5 ns worth; call the input and output >>> of the string A and B. Next, set up an RS flipflop; set it if A and B >>> are both high, and clear it if both are low. Drive the new clock net >>> from that flop. Maybe include a midpoint tap or two in the logic, just >>> for fun. >>> >>> 3. Program the clock logic threshold to be lower. It's not clear to us >>> if this is possible without changing Vccio on the FPGAs. Marginal at >>> best. >>> >>> >>> Any other thoughts/ideas? Has anybody else fixed clock glitches inside >>> an FPGA? >> >>Enable the schmitt option on the pin :) > >Don't I wish! There is a programmable delay element in the IO block, >but it's probably a string of inverters, not an honest R-C delay, so >it likely can't be used to lowpass the edge. We're not sure. > >I wish they'd tell us a little more about the actual electrical >behavior of the i/o bits. I mean, Altera and Actel and everybody else >has snooped all this out already. Xilinx is good with keeping information under their hat. One of the projects I'm currently working on needs a re-design of the PCB because the pin arrangement I had in mind is simply not possible. But the datasheet and application notes don't mention a word about limits on IOBs. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 99952
On Fri, 31 Mar 2006 16:40:39 GMT, nico@puntnl.niks (Nico Coesel) wrote: >> >>I wish they'd tell us a little more about the actual electrical >>behavior of the i/o bits. I mean, Altera and Actel and everybody else >>has snooped all this out already. > >Xilinx is good with keeping information under their hat. One of the >projects I'm currently working on needs a re-design of the PCB because >the pin arrangement I had in mind is simply not possible. But the >datasheet and application notes don't mention a word about limits on >IOBs. Can you be more specific about what went wrong? I thought I knew all the (many) rules about i/o pin behavior and grouping. It's quite a puzzle already. We always pre-assign pins based on what the pcb layout prefers, and design the fpga concurrently with the pcb layout, or more often after it's been sent out to etch. Your situation sounds scairy. I wonder if anyone has ever kluged a bga layout, sort of like one of those jellyfish with a thousand tentacles. JohnArticle: 99953
John Adair wrote: > Basically tool wise they are now same as of version 8.1. Used to be a few > tools were not in Webpack. > > The difference is the devices supported. Webpack only supports the smaller > end and generally lower end devices. Foundation gives you all the currently > recommended for use parts. Some of the buy add-ons may not be available to > Webpack as well. > > John Adair > Enterpoint Ltd. - Home of Hollybush1. The PC104+ Spartan3 Development Board. > http://www.enterpoint.co.uk > > Would you know if it matters whether or not Webpack or Foundation is employed to design a Spartan XC3S400 FPGA?, family of Spartan 3 I believe. -RogerArticle: 99954
faraz.khan@nssi.us schrieb: > Hi Falk thanks for replying. I am using Virtex4FX and primarly my > design will have some user logic embedded on the FPGA and PowerPC 405 > Core. I am batteling on two fronts... Hmmm, your not the first emperor, aeeehhm engineer, who tried this . . . And if history books are correct . . . SCNR ;-) > One to make a user logic on FPGA which will deal with all the I/O and > process the data. > > Second to connect this user logic to BRAM for storage so PowerPC can > use the data. Things are not so simple as i will also have other user > logic also along with this I/O logic which need to be connected to BRAM > so they can access the data. I know that BRAM is dual port RAM so only > two IPs can be attached. I have to use mux for data and address to make > all the IPs access the BRAM as the other port of BRAM will be used by > the processor. So leaving this problem aside. I am trying to UNDERSTAND > how that I/O logic should be designed to grab all the data comming from > outside FPGA. I/O logic will have some registers obviously how can i > use these registers and how can i assign address to these. Again, your talking is still confusing, and Iam afraid your thinking is similar. Sorry, no offence intented. Take a deep breath, relax, and start to draw a very basic diagramm of all major components. Draw arrows to indicated data and control flow. Look at your diagram. Think about it. Then, increase the details in the major components blocks. Regards Falk P.S. Iam afraid you are lacking some basic skills in FPGA design anyway, so maybe you should try to appoach this problem first.Article: 99955
Hello Groups, I have a 1Gbps SERDES output from the Network processor. But as i have 2 SERDES signal coming from the back plane, depending of SEL line i have to connect one of the SERDES to network processor. So i am using FPGA to interface this, which takes a SERDES input and I have FIFO for transmit FIFO, recieve FIFO and FIFO controller and this FIFO is again connected to another SERDES which in turn connect to the Backplane. So i need 4 SERDES for implementing it. Will this intermediate Logic create for end to end SERDES data transfer ? Is there any other way of implementing this logic? I am planning to use Stratix GX FPGA. Please let me know your suggestion, waiting for your reply, KumarArticle: 99956
Nico Coesel schrieb: >>I wish they'd tell us a little more about the actual electrical >>behavior of the i/o bits. I mean, Altera and Actel and everybody else >>has snooped all this out already. > > > Xilinx is good with keeping information under their hat. One of the Really? I doubt it. And NO, Iam not paid by Xilinx ;-) > projects I'm currently working on needs a re-design of the PCB because > the pin arrangement I had in mind is simply not possible. But the > datasheet and application notes don't mention a word about limits on > IOBs. What was the problem? Often enought, people tend to just fly over the datasheets, instead of studing them carefully. All those tiny little footnotes . . . Regards FalkArticle: 99957
HI, Q1.What does FIFO depth mean. Q2.How can i use FIFO to register the signals comming out of FPGA. Q3.How would i address the FIFO. Q4.Can i use Shift register to save incomming outside signals. Q5.How can i address Shift registers. Q6.What is the difference b/w FIFO and shift register I am trying to design a I/O logic how can i use FIFOs or shift registers in it Thanks FarazArticle: 99958
You are right i am very new to FPGA and trying to get a basic idea of how the things work arround. You are also right that i should start from top level down. But i guess i am trying to do so. That's why i asked you how can i grab the data comming out of the FPGA into FPGA. Thanks again FarazArticle: 99959
<faraz.khan@nssi.us> wrote in message news:1143824782.175811.95300@i40g2000cwc.googlegroups.com... > HI, > > Q1.What does FIFO depth mean. > Q2.How can i use FIFO to register the signals comming out of FPGA. > Q3.How would i address the FIFO. > Q4.Can i use Shift register to save incomming outside signals. > Q5.How can i address Shift registers. > Q6.What is the difference b/w FIFO and shift register > > I am trying to design a I/O logic how can i use FIFOs or shift > registers in it > > Thanks > > Faraz > C'mon, Faraz. At least make a little effort to research this on your own. Ever heard of Google? RobArticle: 99960
"Nico Coesel" <nico@puntnl.niks> wrote in message news:442d5a9f.1639975980@news.kpnplanet.nl... > Xilinx is good with keeping information under their hat. One of the > projects I'm currently working on needs a re-design of the PCB because > the pin arrangement I had in mind is simply not possible. But the > datasheet and application notes don't mention a word about limits on > IOBs. Since I've never had an IOB problem in the several generations of Xilinx families I've designed with, what information was lacking from your perspective? (And what device family?)Article: 99961
Hi, I use that book when having SoC Design course. I think that book tells you much about physical design of integrated circuit. The assignments I've got in that course is to do integrated circuit layout. Designing in verilog or vhdl is top level approach. When either speed, power consumption, and area are critical, we have to understand how each building block is constructed. To do so, we need go to the lower levels, understand what topology is used For instance, consider 12 bit adder. We don't even care what topology used when we design it using verilog/vhdl. The library has chosen what seems to be the best, and it would not be a problem as long as it function well. If some application requires speed that we can't achieve, we have to choose which topology suits out needs. There are several topology for adder: carry skip, etc. Different topology gives us different power consumption, processing speed, and area. Some are superior in speed, but have poor power consumption, some are best in area, but not in speed, and that sort of things. If the library doesn't give us such topology, we have to build it by our own. Tanner EDA ver 11 would be a great tool to use for doing the layout, estimating the processing time, power consumption, etc. Hope to help. Any comments are welcome. Ivan mynewlifever@yahoo.com.cn wrote: > =ABDigital integrated circuits.a design perspective(Second > Edition)=BB > Author:Jan.M.Rabaey > > My teach tell me this is a very good book.But now,I am a fresh > person in this field.My mostly work is write verilog code everyday.And > before I studying verilog,micron-electronic is not my major.When I was > a undergraduate student,my major is Elecronic and Infmation > Engneer.So,now,read this book is very hard for me.I also puzzled about > the relation ship between this book and RTL design. > Please help me,thanks!Article: 99962
Whatever people's opinion on the validity of the fix, I think that it's a good time for your engineering team to do some introspection. Think about why this problem wasn't detected before shipping the boards to customers? Should you do some signal integrity checks when bringing up new boards? Have you run the boards in a thermal chamber? Does it make sense to vary the supply voltages too? Should you develop a checklist so that it won't happen again? Etcetera...Article: 99963
> Q1.What does FIFO depth mean. FIFOs are used mostly to store data streams and the depth is the number of storage locations available. The Width, on the other hand, is the number of bits in one data, usually 1, 8, 16, 32, or 64 bits. > Q2.How can i use FIFO to register the signals comming out of FPGA. You apply the signals to the FIFO input, tell the FIFO when to store data with a write enable signal, and read the data off the output with a read enable. > Q3.How would i address the FIFO. FIFOs are different than Memory in that they do not generally have an address. You put data into a FIFO and pull it off later in sequence. > Q4.Can i use Shift register to save incomming outside signals. Yes > Q5.How can i address Shift registers. Shift registers are a little different in that each output can be brought out as a separate output. These are sometimes called taps. Large FIFOs are usually built using a memory and two counters that supply the write address and the read address. > Q6.What is the difference b/w FIFO and shift register Mostly its the taps. Also, there is usually a significant clock delay in a shift register depending directly on its depth because data is shifted from one resgister to the next in a chain. There are special case shift registers called fall-through that is an exception to this. A FIFO built with read and write counter addresses, the delay can be as little as one clock cycle. > I am trying to design a I/O logic how can i use FIFOs or shift > registers in it One area that FIFOs are used is to straddle data between two circuits running on different clocks. These are called asynchrounous FIFOs. Brad Smallridge Ai VisionArticle: 99964
In ModelSim 5.7 I would drag or right click items from a pane called Structure and drag them or add them to the Wave. Where is this or what is the new procedure for 6.0? Brad Smallridge Ai VisionArticle: 99965
fpga_toys@yahoo.com wrote: > Erik Widding wrote: > > Being only C-like and not actually ansi-C, please enlighten me why it > > is important to hold on to one of the aspects of the language (implicit > > zeros which is not universal across all types of variables in the > > language, just in most cases) that kills efficiency when targetting > > hardware, when so many other aspects have to be bastardized to make the > > use of this language for this purpose even possible? > > Actually, the goal for FpgaC is to become a proper subset of ansi-C, > with a few minor additions. And to that end it is NOT correct to > violate certain conventions like zero initialized memory, and making > assignments which are incorrect by the language standard. > > I believe you are very wrong here. The efficiency you claim is being > lost, only exists for illegal programming practice of using an > undefined variable value in a poorly (incorrectly) formed statement > sequence. John, I want to thank you for explaining this for me. It has been educational. I wrote in my second post: > > The remainder of the table can be assumed to have a value of "don't > > care", in many languages this requires a first (or default) assignment > > to the state of "don't care" that may or may not be overridden. The implication in this was that C was one of those languages that would require the implicit assignment to "don't care". If this were accounted for in your analysis of my question it would have resulted in a different understanding of where my question was headed. Though I do realize from your response that being ansi-C compliant is one of the important driving principles in your work. It has been an interesting conversation. I am coming at this from the perspective of an engineer that has degrees in Electrical Engineering and in Computer Science Engineering, that has used at least a dozen languages as a practicing engineer, and seen at least as many in an academic setting. My questions come from the perspective of an end user of the language, who wants to know in advance what the limitations of that language are. We use VHDL rather than Verilog, having used both, because some of the things that we want to do are not easily supported in Verilog, and tolerate the more cumbersome nature of the VHDL language because it does not have these limitations. We do our algorithm development and much of our software in Ansi-C though we use the C++ extensions in the compilers because the strict type checking often catches unintended mistakes. We often write algorithms a first time in C to prove they work, write them a second time in C using the structure that the hardware will actually have, and a third time in VHDL reflecting the exact structure that we want. If FPGAC allowed the third writing to simply be an optimization of the second using the same source code, this would be interesting to us. But from my perspective I will still get the best result for my work with the current strategy, as we need to be able to specify optimizations that are, as you have pointed out, contrary to the c model. I do not mean to insult you by saying that it is interesting work, and may have great application one day for those who would not have even considered an FPGA for the solution, but for me coming from the perspective that an FPGA is a highly probable target, I need the design methodology that is most efficient from both a design cost and silicon cost perspective. Regards, Erik. --- Erik Widding President Birger Engineering, Inc. (mail) 100 Boylston St #1070; Boston, MA 02116 (voice) 617.695.9233 (fax) 617.695.9234 (web) http://www.birger.comArticle: 99966
On 31 Mar 2006 10:22:00 -0800, "Keith" <chen.evans@gmail.com> wrote: >Whatever people's opinion on the validity of the fix, I think that it's >a good time for your engineering team to do some introspection. Think >about why this problem wasn't detected before shipping the boards to >customers? Should you do some signal integrity checks when bringing up >new boards? Have you run the boards in a thermal chamber? Does it make >sense to vary the supply voltages too? Should you develop a checklist >so that it won't happen again? Etcetera... We only sent one V450 to a customer, and that was a freebie, so that they could start writing drivers. We knew something was sometimes slightly funny, but it mostly worked, and we told the guy that it was a beta and would likely need changes. It was during testing here that we looked into the strangeness in detail and found the clock problem. There are about 10 V470's in the field. They have the same clock and fpga's and the same basic layout, but for some reason they all work fine. We will nevertheless upgrade them with the clock deglitcher. And we sure will be more careful about oscillators and clock distribution in the future... everything's getting too fast. It was probably the move of the ground plane to layer 5 of 6 (the clock is mostly routed on 6), and the fast/weak xo, that caused the problem. Clock-on-the-bottom isn't ideal for noise immunity, either. Here's the gadget, but you can't see anything relevant in this pic, just barely the last FPGA in the clock string at the top... http://www.highlandtechnology.com/DSS/V470DS.html The xo is near the bottom, between the metal cover and the eprom, the dark thing poking out. JohnArticle: 99967
I just had a design review on my board and I was zinged for using resistors to pull the M[2:0] pins to power or ground. I have always done it that way and do not see a reason to change. But the Xilinx documents were shown to me, specifically XAPP453, where they clearly show the pins being pulled hard to power or ground. I can't find any info in the data sheet on the threshold levels on these pins (or JTAG), so I can't dispute the argument that I should follow the app note. The same person is saying that an XAPP (which I can't find) indicates that the various JTAG signals need to be pulled low by resistors rather than high. I have always used resistors to pull TCK and TMS high to assure that the JTAG port was not put in an invalid state. The TDI and TDO signals were not important. I am aware that these pins are 2.5 volts. Is that why they are shown pulled to ground, to avoid any confusion about *which* high? Any official source of info on this? I have looked on the Xilinx web site, but there are dozens of documents that score a hit on JTAG and Spartan and I don't see any that answer the questions.Article: 99968
On 30 Mar 2006 22:22:07 -0800, "Jeff Brower" <jbrower@signalogic.com> wrote: >John- > >> Except that I can flip through a 20-page schematic and not only >> understand what it does, I can usually spot hazards and bugs quickly, >> sometimes in seconds. Nobody can do that with a few thousand lines of >> uncommented HDL. >> >> Parallel beats sequential, which is what FPGAs are all about. >> >> And if they call you Gramps, it's easy enough to fire them and hire a >> fresh batch. > >Sure if it's OrCAD, which we use it for complex board designs. Yes you >can spot errors fast and things jump out that can save your board >desgin. PADS has a beautiful schematic editor. > >But ISE? A 20 page schematic in ISE is like trying to cut concrete >with knife. You can do it, but only if you have a LOT of time on your >hands, maybe for example a need to escape from prison :-) > Well, the library symbols sure are hideous. What *were* they thinking? Too bad there's no universal schematic file format. Schematics would be more pleasant if, for example, old Foundation schematics could be imported into ISE; it's criminal that they can't. LT Spice seems to have a nice external ASCII file format for expressing schematics. JohnArticle: 99969
Hi There, I've managed to compile a sample aurora protocol design using Coregenerator, and simulated it using ModelSim. I have a couple of questions at this point. I'm trying to download the design onto the board using IMPACT. All the processes (Program, Get Device ID, Read Status Register.. ) seem to work except the Verify process. Is that something that I should be concerned about.Can I assume that design has been uploaded to the board, once I run program, and it says program successful? How do I test the design on the board. Is there a simple to way to demonstrate a link between two transceivers and monitor the status. I'm guessing theres something possible with Chipscope, but I dont have access to the program. Thx in advance, BilluArticle: 99970
I would like to obtain a Virtex II Pro 20K part in FG676 package for prototyping. I am in the UK and have seen the part on Digikey for around $320. Does seem like a good price or does anyone know of a cheaper alternative. Or would it be possible to get a one off sample? Cheers JonArticle: 99971
John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >On Fri, 31 Mar 2006 16:40:39 GMT, nico@puntnl.niks (Nico Coesel) >wrote: > > >>> >>>I wish they'd tell us a little more about the actual electrical >>>behavior of the i/o bits. I mean, Altera and Actel and everybody else >>>has snooped all this out already. >> >>Xilinx is good with keeping information under their hat. One of the >>projects I'm currently working on needs a re-design of the PCB because >>the pin arrangement I had in mind is simply not possible. But the >>datasheet and application notes don't mention a word about limits on >>IOBs. > >Can you be more specific about what went wrong? I thought I knew all >the (many) rules about i/o pin behavior and grouping. It's quite a >puzzle already. I've designed a DDR200 memory interface in a Spartan3 200k gates device. A quick introduction: DDR memory has a bi-directional data clock (DQS) which is driven by the memory when data is read and driven by the FPGA when the data is written into the memory. This means I need to use a local clock for every byte lane (4 lanes in total) to clock the data into the device or drive DQS from the internal clock. This caused 2 problems: 1) It turns out not every pin can be routed efficiently to form a low delay local clock to clock adjacent pins. Worse, only the top and bottom sides of the FPGA (the clock pins are on the left and right sides) feature real fast routing between IOBs. Determining the right pins to use is a trial-and-error process. 2) It also appears most IOBs are actually implemented as a dual IOB elements which share certain pins, including the clock pin. This means that it is not possible to have a DQS line share a 'dual IOB' with a data pin since two different clocks are required. I can't find any references to these limitations in the datasheet. A DDR memory interface application note makes a short notice of some limitations on placement, but thats all there is. I did manage to bypass these problems on my prototype with some additional wiring to connect the DQS to some unused pins and use an internal clock to capture the data. This works for now, but I don't want to put this solution into a production device. >We always pre-assign pins based on what the pcb layout prefers, and >design the fpga concurrently with the pcb layout, or more often after >it's been sent out to etch. Your situation sounds scairy. I did the same. I designed the PCB first after studying the FPGA datasheet thouroughly. I even created the possibility to use the DCI (digitally controlled impedance). -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 99972
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:1143833043.040499.197510@u72g2000cwu.googlegroups.com... >I just had a design review on my board and I was zinged for using > resistors to pull the M[2:0] pins to power or ground. I have always > done it that way and do not see a reason to change. But the Xilinx > documents were shown to me, specifically XAPP453, where they clearly > show the pins being pulled hard to power or ground. > > I can't find any info in the data sheet on the threshold levels on > these pins (or JTAG), so I can't dispute the argument that I should > follow the app note. > > The same person is saying that an XAPP (which I can't find) indicates > that the various JTAG signals need to be pulled low by resistors rather > than high. I have always used resistors to pull TCK and TMS high to > assure that the JTAG port was not put in an invalid state. The TDI and > TDO signals were not important. I am aware that these pins are 2.5 > volts. Is that why they are shown pulled to ground, to avoid any > confusion about *which* high? Any official source of info on this? > > I have looked on the Xilinx web site, but there are dozens of documents > that score a hit on JTAG and Spartan and I don't see any that answer > the questions. > Rick - You're right about the M[2:0] pins. No reason to get rid of the resistors, but they're not needed. The only caveat for pulling high is that these pins are powered by VCCAUX, so pull (or tie) them to 2.5V. As for pull downs, these pins are weakly pulled up internally, so if you pull them low just don't use a huge value. Don't read too much into XAPP453. Those are just logical drawings anyway. (By the way, in Spartan-3E the M[2:0] pins are general-purpose I/O and are not powered by VCCAUX.) For the JTAG pins, read record #11433 in the Xilinx answers database. It says to pull TMS and TDI high through 4.7K and let TCK float. I usually see TCK also pulled high, but with TMS high it shouldn't matter. Again, though, the JTAG pins are powered by VCCAUX, so pull to +2.5V unless you follow the guidelines to support 3.3V configuration. RobArticle: 99973
RobJ wrote: > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:1143833043.040499.197510@u72g2000cwu.googlegroups.com... > >I just had a design review on my board and I was zinged for using > > resistors to pull the M[2:0] pins to power or ground. I have always > > done it that way and do not see a reason to change. But the Xilinx > > documents were shown to me, specifically XAPP453, where they clearly > > show the pins being pulled hard to power or ground. > > > > I can't find any info in the data sheet on the threshold levels on > > these pins (or JTAG), so I can't dispute the argument that I should > > follow the app note. > > > > The same person is saying that an XAPP (which I can't find) indicates > > that the various JTAG signals need to be pulled low by resistors rather > > than high. I have always used resistors to pull TCK and TMS high to > > assure that the JTAG port was not put in an invalid state. The TDI and > > TDO signals were not important. I am aware that these pins are 2.5 > > volts. Is that why they are shown pulled to ground, to avoid any > > confusion about *which* high? Any official source of info on this? > > > > I have looked on the Xilinx web site, but there are dozens of documents > > that score a hit on JTAG and Spartan and I don't see any that answer > > the questions. > > > > Rick - > > You're right about the M[2:0] pins. No reason to get rid of the resistors, > but they're not needed. The only caveat for pulling high is that these pins > are powered by VCCAUX, so pull (or tie) them to 2.5V. As for pull downs, > these pins are weakly pulled up internally, so if you pull them low just > don't use a huge value. Don't read too much into XAPP453. Those are just > logical drawings anyway. (By the way, in Spartan-3E the M[2:0] pins are > general-purpose I/O and are not powered by VCCAUX.) > > For the JTAG pins, read record #11433 in the Xilinx answers database. It > says to pull TMS and TDI high through 4.7K and let TCK float. I usually see > TCK also pulled high, but with TMS high it shouldn't matter. Again, though, > the JTAG pins are powered by VCCAUX, so pull to +2.5V unless you follow the > guidelines to support 3.3V configuration. This answers record is the sort of thing I was looking for. I do find it bizzar that they say to not bother with tieing TCK high. I thought *ALL* CMOS inputs should be tied high or low to prevent them from sitting in the middle and drawing higher currents. I have an email into one of the Xilinx FAEs here. We'll see what he has to say. When you need one of the Xilinx guys they can be hard to find.Article: 99974
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:ot0r22p8pdcr2g956ef1ln8h852ll9s7g2@4ax.com... > On 30 Mar 2006 22:22:07 -0800, "Jeff Brower" <jbrower@signalogic.com> > wrote: > >>John- >> >>> Except that I can flip through a 20-page schematic and not only >>> understand what it does, I can usually spot hazards and bugs quickly, >>> sometimes in seconds. Nobody can do that with a few thousand lines of >>> uncommented HDL. >>> >>> Parallel beats sequential, which is what FPGAs are all about. >>> >>> And if they call you Gramps, it's easy enough to fire them and hire a >>> fresh batch. >> >>Sure if it's OrCAD, which we use it for complex board designs. Yes you >>can spot errors fast and things jump out that can save your board >>desgin. > > PADS has a beautiful schematic editor. > >> >>But ISE? A 20 page schematic in ISE is like trying to cut concrete >>with knife. You can do it, but only if you have a LOT of time on your >>hands, maybe for example a need to escape from prison :-) >> > > Well, the library symbols sure are hideous. What *were* they thinking? > > Too bad there's no universal schematic file format. Schematics would > be more pleasant if, for example, old Foundation schematics could be > imported into ISE; it's criminal that they can't. > > LT Spice seems to have a nice external ASCII file format for > expressing schematics. > > John > Now if you use the Altera Quartus schematic capture I personally believe you get a superb set of tools and symbols. Here is an example I dropped together inside 3 mins, ready to synthesise. Only needs the pins and device defining before I can drop it straight into a part. http://www.wheelnut.plus.com/Block1_bdf.pdf I bet not many engineers cannot see what the intent is in this extreme trivial example.... ..... as opposed to shedloads of VHDL which would take a week and numerous sketches to work out what is going on, looking for typos and missed declarations etc. But then I am just an old Gramp and prefer a cushy life. Slurp
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