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 Sat, 20 Sep 2003 23:19:37 -0700, Simon Peacock wrote: > I have a feeling you might be pushing it .. but I'd like to hear the > outcome.. The parallel port is treated as a bit bashed I/O port by the > downloader's where as the USB to parallel port is a printer port.. or an > EPP port.. > > Xilinx do a USB to FPGA downloader box for about US$500.. that would be > my best thought.. or there's a few USB - JTAG boxes that might also > work. Altera have a similar device similar price.. > > I have often thought an EZ-USB would make a great FPGA downloader and at > the same price as the parallel port downloader's. > > Simon > > > "CF" <carl@notsoform.com> wrote in message > news:_e4bb.2249$YO5.1748748@news3.news.adelphia.net... >> Thank you for confirming my suspicion that I cannot accomplish this >> task with a USB adapter. >> I have ordered a Quatech SPP-100 PCMCIA to Parallel adapter. I believe >> it will install as an LPT device properly and do the job. Thank you >> again. >> Carl >> A little early to announce but we have a simple USB/JTAG downloader. The downloader uses the FTDI245B chip + a SpartanII Xc2S50 for the TAP controller. The XC2S50 is first downloaded in bit-bang mode via the FTDI chip and then acts as a smart TAP controller. This is an open project with all design information (software, stiffware, schenmatics, gerbers) freely available. The downloader supports 2.5V, 3.3V and 5V JTAG I/O and programmable clock rates up to 48 MHz. The programmer is USB powered (no adapter needed). Connector pinout is 26 pin superst of EJTAG pinout. The current software allows downloading Xilinx Bit files and SVF files (Thanks Jim!) If you dont want to build it yourself, The programmer hardware is available from my company for $99.00 Peter Wallace >> >>Article: 60751
"Hans" <hansydelm@no-spam-ntlworld.com> wrote in message news:<1nzab.364$4G3.59567@newsfep2-gui.server.ntli.net>... > Try (bash), > > export LD_ASSUME_KERNEL=2.4.1 > > It runs fine on my RH9, > Hans. > www.ht-lab.com Thanks Hans I will do it tonight GarryArticle: 60752
CF wrote: > Thank you for confirming my suspicion that I cannot accomplish this task > with a USB adapter. > I have ordered a Quatech SPP-100 PCMCIA to Parallel adapter. > I believe it will install as an LPT device properly and do the job. You made the right choice, I have one of these for my laptop and it works perfectly. By all accounts UCB->parallel converters just won't work with iMPACT. Regards, JohnArticle: 60753
john.l.smith@titan.com (John) wrote in message news:<5b9931fd.0309181642.739c694b@posting.google.com>... > "Theron Hicks" <hicksthe@egr.msu.edu> wrote in message news:<bkcrmn$iah$1@msunews.cl.msu.edu>... > > Hello, > <in Spartan3> > >> what is the fastest I can do a 16bit divide (unsigned) > Thanks, > > Theron Hicks > > Perhaps try table lookup using blockram, followed by Newton-Raphson > iteration..see for example: > http://citeseer.nj.nec.com/oberman95analysis.html > HTH > John This may be helpful: http://citeseer.nj.nec.com/rice98multiprecision.html TomArticle: 60754
Hi everybody!! I trying to use the core "1024 points fft v2.0" from Xilinx, but I have the problem that I don't get the correct result. I'm using a constant input of 0001(Hex) for real and 0000(Hex) for imaginary. During the intermediate steps of the fft, the core seems to be coming up with strange values that it writes to memory and the error propagates to the output. I have simulated the 64 and 256 points ffts from Xilinx and they work properly. I think that maybe I'm not using the correct input data range, I know that input data must be in two's complement format. I'm using ISE 4.1 and for simulation I use Modelsim XE II v5.6e (starter). thanks for your attention and I would appreciate your help very much.Article: 60755
To Peter, Paul and all the other apostles... :) My point is that as an engineer, I can figure out what is best for my design. If I can't, then shame on me. But giving me phoney numbers (which is what the Xilinx cell counts are no matter how marketing justifies them) just makes the vendor look bad to engineers. If Xilinx has better cells, then tell me that! Don't try to tell me you have more cells than you really do, that is utter nonsense!!! I have always and expect *will* always resent the "spin" that marketing puts on what is really a very technical business. I remember the first time I noticed an overly "marketized" web site that was hard to view because of the large graphic files that added nothing to the information I wanted. I also remember the first time an information file was altered by marketing so much that it was not usable on any of the machines I had available. I have yet to see any added value in any of the documentation or even in the advertising that the marketing people put out. Heck, it was only a few weeks ago that I even learned what a "platform" chip was after having read about it in FPGA advertising for what... three or four years? Before we let Shakespeare kill all the lawyers, let's kill all the marketeers! Paul Leventis wrote: > > I might as well give the Altera view -- 12.5% is a gross overstatement of > the relative abilities of a Virtex LC vs. a Stratix LE. Our data suggests > that nearly the reverse is true (about a 9% advantage for Stratix). Please > see the following whitepaper for our reasoning and data. As you can see > from Figure 1, your mileage will vary -- depending on your design, you could > see vast density advantages from one architecture or the other. ...snip... > "Peter Alfke" <peter@xilinx.com> wrote in message > news:3F69D605.63B715DB@xilinx.com... > > Rick, I will not defend the +12,5%, but I can explain it: ...snip... -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 60756
Mikeandmax wrote: > > cadnewbie found a gem - > > >Recently came across an old FPGA circuit board, its an ORCA Version > >1.0 evaluation module. It looks quite antiquated and came with no > >manuals or softwares whatsoever. I am wondering if there are any > >softwares out there on the net that I can find for it. Might be able > >to put it to some good use if I can find the darn softwares or at the > >very least documents, data sheets. Anyone know anything about it? > > > Don't have a lot of information on what you have in hand - but Lattice is now > the company building the ORCA FPGA products, and developing new devices and > families based on this technology. > The history lesson is a bit long: > ATT and Xilinx were once partnered for early XLX FPGAs, with ATT being a > foundry source - > at some point the partnership dissolved - and ATT created it's own family > called ORCA( for Optimized Reconfigurable Component Array) - > ATT spun off LUCENT (with microelectronics along for the ride) > Lucent spun off AGERE (with microelectronics along, essentially this is AGERE) > AGERE sold off the ORCA technology, along with ASIC technology used for > high-end SERDES based FPSC, to Lattice Semiconductor. > Lattice now builds and develops device families based on the technology > acquired. > So, I guess check the lattice website, at least you will find the datasheets > for the device on the pcb, and software to design and develop these devices as > well. > Good luck with your project, I would suggest a call to your Lattice FAE - > > Michael Thomas > Lattice SFAE > NY/NJ If you are really interested, I have the old ORCA software for schematic entry using Workview (included). It may use a hardware key, I don't remember. I must have one around, but it may take a bit to find it. The software however, I have handy if you are interested. But my advice is to toss the board and deny ever having found it. :) -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 60757
Hi Srikanth Have you thought about using CPLDs? Xilinx offer the coolrunner II kits for around $49. I have bought one for my own development purposes and it seems to be fairly straight forward in use and has many I/Os. Naveed "Srikanth Anumalla" <srikanth@unlserve.unl.edu> wrote in message news:SJ0ab.27397$NM1.21271@newsread2.news.atl.earthlink.net... > Jesse Kempa wrote: > > > I'm not sure what your cost requirements are, but for getting off the > > ground one recently released development platform comes to mind.... > > check out Omniwerks (www.omniwerks.com), who offers a complete 802.11 > > FPGA/Embedded CPU development kit, with board/software/IP. They use > > the Nios CPU & uc/OS II operating system on the software side. > > > > Jesse Kempa > > Altera Corp. > > jkempa at altera dot com > > > > > > > > > >>The reason I went for fpga was to have wireless networking (802.11) > >>Actually, the sensors are 3-4 miles apart, I need the data until a > >>base station from where I will transfer the data to the internet. > >>the base station is located in the filed and will be 1-2 miles distant > >>from each sensor. So how do I transfer (in realtime) the data until the > >>base station from the sensor. Is it possible with PCI micro. > >>Please suggest me if there is a better solution other than fpga cpu > >>for doing this (wireless networking). > >> > >>Thanks in advance > >>Srikanth > > I know development kits costs are high. Suppose If I want to have 10 > such embedded system, do I need to have 10 development kits, I am very > new to this, so please ignore my nonsence if any. > > Srikanth >Article: 60758
I just noticed that HDD manufacturers are getting sued over binary Megabyte vs. decimal megabyte.. perhaps they could do Xilinx when they are finished ?? :-) But seriously..I hope Xilinx are watching.. I think the same rules would have to apply here. chickens are chickens just don't count them until they hatch :-) Simon "rickman" <spamgoeshere4@yahoo.com> wrote in message news:3F6E9C13.3B65F43E@yahoo.com... > To Peter, Paul and all the other apostles... :) > > My point is that as an engineer, I can figure out what is best for my > design. If I can't, then shame on me. But giving me phoney numbers > (which is what the Xilinx cell counts are no matter how marketing > justifies them) just makes the vendor look bad to engineers. If Xilinx > has better cells, then tell me that! Don't try to tell me you have more > cells than you really do, that is utter nonsense!!! > > I have always and expect *will* always resent the "spin" that marketing > puts on what is really a very technical business. I remember the first > time I noticed an overly "marketized" web site that was hard to view > because of the large graphic files that added nothing to the information > I wanted. I also remember the first time an information file was > altered by marketing so much that it was not usable on any of the > machines I had available. I have yet to see any added value in any of > the documentation or even in the advertising that the marketing people > put out. Heck, it was only a few weeks ago that I even learned what a > "platform" chip was after having read about it in FPGA advertising for > what... three or four years? > > Before we let Shakespeare kill all the lawyers, let's kill all the > marketeers! > > > Paul Leventis wrote: > > > > I might as well give the Altera view -- 12.5% is a gross overstatement of > > the relative abilities of a Virtex LC vs. a Stratix LE. Our data suggests > > that nearly the reverse is true (about a 9% advantage for Stratix). Please > > see the following whitepaper for our reasoning and data. As you can see > > from Figure 1, your mileage will vary -- depending on your design, you could > > see vast density advantages from one architecture or the other. > > ...snip... > > > "Peter Alfke" <peter@xilinx.com> wrote in message > > news:3F69D605.63B715DB@xilinx.com... > > > Rick, I will not defend the +12,5%, but I can explain it: > > ...snip... > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 60759
Now this sounds like a plan.. I would be interested in more info.. as would a few around here.. Simon "Peter Wallace" <pcw@karpy.com> wrote in message news:pan.2003.09.21.22.57.55.531717.20522@karpy.com... > On Sat, 20 Sep 2003 23:19:37 -0700, Simon Peacock wrote: > > > I have a feeling you might be pushing it .. but I'd like to hear the > > outcome.. The parallel port is treated as a bit bashed I/O port by the > > downloader's where as the USB to parallel port is a printer port.. or an > > EPP port.. > > > > Xilinx do a USB to FPGA downloader box for about US$500.. that would be > > my best thought.. or there's a few USB - JTAG boxes that might also > > work. Altera have a similar device similar price.. > > > > I have often thought an EZ-USB would make a great FPGA downloader and at > > the same price as the parallel port downloader's. > > > > Simon > > > > > > "CF" <carl@notsoform.com> wrote in message > > news:_e4bb.2249$YO5.1748748@news3.news.adelphia.net... > >> Thank you for confirming my suspicion that I cannot accomplish this > >> task with a USB adapter. > >> I have ordered a Quatech SPP-100 PCMCIA to Parallel adapter. I believe > >> it will install as an LPT device properly and do the job. Thank you > >> again. > >> Carl > >> > > > A little early to announce but we have a simple USB/JTAG downloader. The > downloader uses the FTDI245B chip + a SpartanII Xc2S50 for the TAP > controller. The XC2S50 is first downloaded in bit-bang mode via the FTDI > chip and then acts as a smart TAP controller. This is an open project with > all design information (software, stiffware, schenmatics, gerbers) freely > available. > > The downloader supports 2.5V, 3.3V and 5V JTAG I/O and programmable clock > rates up to 48 MHz. The programmer is USB powered (no adapter needed). > Connector pinout is 26 pin superst of EJTAG pinout. > > The current software allows downloading Xilinx Bit files and SVF files > (Thanks Jim!) If you dont want to build it yourself, The programmer > hardware is available from my company for $99.00 > > > Peter Wallace > > > >> > >>Article: 60760
passing thought ~~~ there exists one ultimate natural machine, design of which can't even be copied :) philosophy is a junk isn't it. --ykaArticle: 60761
Hi guyes ,
Does any body have datasheet for XC6216 ?
Article: 60762In order to double my input clock of 48 MHz, I'm using a CLKDLL. I understand that I have to add a timing constraint so the synthesizer knows what frequency I'm operating at. I added the following to my .ucf file: NET "clk48" TNM_NET = "clk48"; TIMESPEC "TS_clk48" = PERIOD "clk48" 48 MHz HIGH 50 %; NET "clk96" TNM_NET = "clk96"; TIMESPEC "TS_clk96" = PERIOD "clk96" "TS_clk48" / 2; However, ngdbuild gives an error saying "clk96" could not be found in the design. Xilinx' support page http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1& iCountryID=1&getPagePath=17222 tells me to check if the name is the same as in the top-level netlist, which seems to be implementation/system.ngc, and is a binary file. Which is the source file where my "clk96" should be mentioned, and do I have to do something more to get it there? Right now, clk96 is only a signal in one of my VHDL architectures. Thanks HeikoArticle: 60763
Hi, Can somebody please tell me who the moderator of this newsgroup is? Thanks, Stephan NeuholdArticle: 60764
This post may seem a bit awkward, but has anyone ever come across a VHDL or Verilog implementation of an FPGA? It would be very instructional to have a look at it. IMHO, it should be at any rate possible to implement a small FPGA as a bit file sitting on top of another FPGA. Our group is currently working on some ideas for minimizing the reconfiguration data in dynamically reconfigurable FPGA applications. It would be very kind if anyone could point me to any resources... Thank you so much in advance... SebastianArticle: 60766
"Valeria Dal Monte" <aaa@bbb.it> wrote in message news:<9qkbb.335067$Ny5.10649409@twister2.libero.it>... > Some days ago Xilinx did workshops in many european states. > Why Italy was excluded? No workshops in UK either :(Article: 60767
On 22 Sep 2003 06:26:07 -0700, Sebastian_Lange@gmx.de (Sebastian Lange) wrote: >This post may seem a bit awkward, but has anyone ever come across a >VHDL or >Verilog implementation of an FPGA? It would be very instructional to >have a >look at it. IMHO, it should be at any rate possible to implement a >small FPGA as a bit file sitting on top of another FPGA. Our group is >currently working on some ideas for minimizing the reconfiguration >data in dynamically reconfigurable FPGA applications. >It would be very kind if anyone could point me to any resources... >Thank you so much in advance... > >Sebastian Eric Crabill's course at SJSU covers this as Lab 5 http://www.engr.sjsu.edu/crabill/ Philip Freidin FliptronicsArticle: 60768
I am using one counter to trigger a second counter.
The first counter is loadable but typically runs for a long time ('count' is
28 bit).
This counter keeps running, and each time it terminates, produces a pulse.
This pulse is used to trigger the second counter, which typically runs for
much less time ('count' is 8 bit). This counter produces output 1 while it
is counting, then returns to 0 until it is retriggered by the pulse from the
first counter.
The whole design is synchronous (running of a single clock at 100 MHz),
using Webpack on Spartan IIE.
Question: how long must the pulse from the first clock be, to ensure that it
triggers the second clock? As I see it, if it is one clock cycle long, then
the second clock should trigger on the next clock rising edge (providing the
sum of clock propagation and the 2nd clock flip-flop setup is less than one
clock cycle)... but functionally the pulse will fall back at the moment it
is triggered (one cycle later), so will only work if the hold time of the
flip-flop is less than the clock propagation.
Is this safe? Does the pulse need to be longer? Will the simulation tools
realise if there is a problem here?
Many thanks
Tom Derham
Article: 60769Simon, That is for the lazy folks: if you know the reliability (from studies, manufacturers data, etc.) you can choose to replace the "count method" with the real data (wow, what a concept!). The "count method" is there as a last resort, if there is no other way to gauge reliability. Once you see the count method numbers, it should send you screaming to get the real data. The standards bodies know this, and understand this, it is just that lazy engineers just keep filling out the forms as if they were still designing in 1968 .... Our reliability group is happy to provide the latest and most up to date reliability information for completing these studies properly (per the standard). Please make the request thru the hotline. Austin Simon Peacock wrote: > I think that's because one of the standards counts transistors in its MTBF.. > so a PAL is more reliable than an FPGA but less reliable than an HC00. > > Simon > > "Peter Alfke" <peter@xilinx.com> wrote in message > news:3F6B9895.CB08B483@xilinx.com... > > I think the answer is " more than 100 million, but less than 300 million". > > > > We are caught between embarrassment: "that's how many we need" and > > pride: "that's how good we are, to be able to make and sell that many > > for a reasonable price". > > > > An then there still are some people who really and seriously (!) think > > they can calculate device reliability and MTBF from the total number of > > transistors. These guys do not seem to die out, even though we have told > > them, and proven to them, again and again, that such calculations are > > utter nonsense. > > > > So Ray is right, you would need another seven or eight fingers... > > Peter Alfke > > ======================== > > Ray Andraka wrote: > > > > > > More than you can count on both hands and feet, even if you count in > binary > > > :-) > > > > > > Arnaldo Oliveira wrote: > > > > > > > Hi! > > > > > > > > Could someone tell me how many transistors are integrated on the > XC3S5000 > > > > Spartan-3 device? > > > > Thank You. > > > > Arnaldo. > > > > > > > > -- > > > > > > -- > > > --Ray Andraka, P.E. > > > President, the Andraka Consulting Group, Inc. > > > 401/884-7930 Fax 401/884-7950 > > > email ray@andraka.com > > > http://www.andraka.com > > > > > > "They that give up essential liberty to obtain a little > > > temporary safety deserve neither liberty nor safety." > > > -Benjamin Franklin, 1759Article: 60770
Hello Xilinx, are you there??? lecroy7200@chek.com (lecroy) wrote in message news:<9297c711.0309150524.12171322@posting.google.com>... > Peter Alfke <peter@xilinx.com> wrote in message news:<3F62569A.BB3294B0@xilinx.com>... > > What happens at 25 ohms?? > > > > My answer would be: NO. > > But I have copied Steve Knapp, > > who handles Spartan applications. He may add his opinion to this. > > This is what I have been running into. There seems to be no one at > Xilinx who is sure. I had hoped that with this news group being a bit > more visable that I could find the right person to ask. Here is David > Anderson’s and Paul’s (who both work for Xilinx) responses > which are different from yours. In Paul's note, he even talks about > asking the factory. > > > > ***************************************** > > So yes the reflected energy can still cause damage, but again if you > limit > the current to 10mA there shouldn't be any damage. This will be the > same > limitations as if this was an input. So you can refer to the max > specs > in the first page of the datasheet. See link below: > http://direct.xilinx.com/bvdocs/publications/ds099-3.pdf > Mainly you need to take a look at Vin and note 4. When VCCO is 3.0 V > or > less, VIN overshoot may go as high as VCCO + 1.0 V for up to 11 ns > provided > that the current entering the I/O pin is limited to 10 mA. Also, when > VCCO > is 3.0 V or less, VIN undershoot may go as low as -1.0 V for up to 11 > ns > provided that the current entering the I/O pin is limited to 10 mA. > > Hope this helps. > > Regards, > David Anderson > > ***************************************** > > > Going back to your original question, the answer back from the factory > is at > 3.3 V signaling, it is possible to have reflections damage the part. > If you have a particular circuit that you would like to model for you > we can > do that. > > In general, IBIS simulation is the way to go in, to insure signal > integrity > (especially for high speed designs). It should be possible to use the > XCITE > technology to use a few resistors to impedance match the board layout, > assuming that most trace lengths are about the same. Should a few > signals be > much longer/shorter, XCITE or DCI can be disabled on an IO by IO > basis, and > these pins can then be terminated separately, if necessary (do IBIS > simulation to see if overshoot will be a problem). > > Hope this helps, > Paul > > ***************************************** > > > I know we have gone back and forth on this, but I think the answer is > that > there is not an issue. The from what I have seen, the IO on the > Spartan III > are speced the same as the Virtex II Pro, regarding maximum voltage, > and > reflections are not an issue with Virtex II Pro. > > Brain, > > Please correct me if I am wrong. Again, I believe the initial > response was > wrong, and that reflections cannot damage the IO. Also, what data can > we > provide that backs our position. > > Thanks, > PaulArticle: 60771
lecroy, Of course we are here, and reading. The confusion is (to many) that the question is what does the reflection back to the driver do to the driver, right? This is a fairly obscure distinction, so I would not expect every one of the 200+ hotline CAEs to get it perfectly right on the first try. Did you submit multiple cases? Or call some folks you know? (IE how did you get multiple answers...) It would help if you worked this thru the hotline, as they need to learn from their mistakes, and improve their service sometimes. If you are talking about it here, then we are not closing the loop! Well, if the PMOS is ON, then it is really hard for a reflection to drive the output pin to a voltage that is higher than the specification. Conversely, if the NMOS is ON, then it is really hard for the reflection to drive the output pin below ground. Look at the IBIS simulation at the output pin to see what the voltage excursions are, an be sure they stay within the specifications sheet and user's guide. If you have a specific waveform, you may email it to me directly, and I will get the "final word" from the designers and technology groups. But let me know the case number, so I can make sure that the hotline is kept in the loop. Austin lecroy wrote: > Hello Xilinx, are you there??? > > lecroy7200@chek.com (lecroy) wrote in message news:<9297c711.0309150524.12171322@posting.google.com>... > > Peter Alfke <peter@xilinx.com> wrote in message news:<3F62569A.BB3294B0@xilinx.com>... > > > > What happens at 25 ohms?? > > > > > > > My answer would be: NO. > > > But I have copied Steve Knapp, > > > who handles Spartan applications. He may add his opinion to this. > > > > This is what I have been running into. There seems to be no one at > > Xilinx who is sure. I had hoped that with this news group being a bit > > more visable that I could find the right person to ask. Here is David > > Anderson’s and Paul’s (who both work for Xilinx) responses > > which are different from yours. In Paul's note, he even talks about > > asking the factory. > > > > > > > > ***************************************** > > > > So yes the reflected energy can still cause damage, but again if you > > limit > > the current to 10mA there shouldn't be any damage. This will be the > > same > > limitations as if this was an input. So you can refer to the max > > specs > > in the first page of the datasheet. See link below: > > http://direct.xilinx.com/bvdocs/publications/ds099-3.pdf > > Mainly you need to take a look at Vin and note 4. When VCCO is 3.0 V > > or > > less, VIN overshoot may go as high as VCCO + 1.0 V for up to 11 ns > > provided > > that the current entering the I/O pin is limited to 10 mA. Also, when > > VCCO > > is 3.0 V or less, VIN undershoot may go as low as -1.0 V for up to 11 > > ns > > provided that the current entering the I/O pin is limited to 10 mA. > > > > Hope this helps. > > > > Regards, > > David Anderson > > > > ***************************************** > > > > > > Going back to your original question, the answer back from the factory > > is at > > 3.3 V signaling, it is possible to have reflections damage the part. > > If you have a particular circuit that you would like to model for you > > we can > > do that. > > > > In general, IBIS simulation is the way to go in, to insure signal > > integrity > > (especially for high speed designs). It should be possible to use the > > XCITE > > technology to use a few resistors to impedance match the board layout, > > assuming that most trace lengths are about the same. Should a few > > signals be > > much longer/shorter, XCITE or DCI can be disabled on an IO by IO > > basis, and > > these pins can then be terminated separately, if necessary (do IBIS > > simulation to see if overshoot will be a problem). > > > > Hope this helps, > > Paul > > > > ***************************************** > > > > > > I know we have gone back and forth on this, but I think the answer is > > that > > there is not an issue. The from what I have seen, the IO on the > > Spartan III > > are speced the same as the Virtex II Pro, regarding maximum voltage, > > and > > reflections are not an issue with Virtex II Pro. > > > > Brain, > > > > Please correct me if I am wrong. Again, I believe the initial > > response was > > wrong, and that reflections cannot damage the IO. Also, what data can > > we > > provide that backs our position. > > > > Thanks, > > PaulArticle: 60772
Rider, When configuring the FPGA via JTAG, iMPACT will provide TCK. When configuring the FPGA via PROM with Master Serial Setup, CCLK is provided by the FPGA. At the end of configuration, the FPGA will enter the startup sequence. Treat this sequence as a state machine that the FPGA needs to go through before "waking up". This sequence is where you can set the options of when you want the DONE pin to go high, the IO tri-state to be released, etc. To get through this startup sequence, you'll need to provide clocks. Generally, when configuring via JTAG, you would select startup clock to be JTAGCLK since you're already providing TCK. So when configuring with PROM, you would want to set startup clock to CCLK unless you'll be seperating providing TCK (JTAGCLK) or even userclock to clock through the startup sequence. And as for PROM file generation or ACE file generation, the iMPACT help topic has been vastly improved in 6.1i. If anything isn't clear, please do contact the Xilinx Hotline Support. As far as support for patform flash proms, please make sure you use 5.2i service pack 3 for file generation. Regards, Wei Xilinx Applications rider wrote: > Hi! > Thanks for the group to reply my previous query "Xilinx Parallel Cable > 4 (PC4) and Platform Flash JTAG". Specially to Antti Lorenzo and > Aurelian Lazarut. Continuing with the same topic of configuration, i > have a few more queries: > > 1)In the Xilinx's latest document "Configuration Quick Start > Guidelines" http://www.xilinx.com/bvdocs/appnotes/xapp501.pdf page 13, > the author shows a snap from iMPACT software(fig: 9 Startup options > for Virtex and Spartan 2). The author states: > > "Start-Up Clock – The bitstream must be generated with the appropriate > startup clock option for the PART to be configured properly. The > "Start-Up Clock" option by default is set to "CCLK" for Master Serial > Mode. When generating a bitstream for Boundary Scan (JTAG) Mode the > option must be set to "JTAGCLK" in the pull-down menu of the GUI or > using bitgen's command line: > • For configuring using Boundary Scan (JTAG): > bitgen –g startupclk:jtagclk designName.ncd > • For configuring via Master-Serial: > bitgen –g startupclk:cclk designName.ncd" > > My question is that when she talks of Master Serial Mode and CCLK, > does she mean she is creating a file for PROM only[PART is PROM here], > because Master Serial mode requires a PROM . The file cannot be loaded > directly to FPGA. And when she talks of JTAG and jtagclk, the PART > could be PROM or FPGA ? Am i right ? > > 2) I have Xilinx ISE5.1 , does it support the configuration of latest > Xilinx Platform PROM XCF02S via JTAG? > > ThanksArticle: 60773
"Tom Derham" <tderham@NOSPAM.ee.ucl.ac.uk> wrote in message
news:bkn1gm$d00$1@uns-a.ucl.ac.uk...
> I am using one counter to trigger a second counter.
> The first counter is loadable but typically runs for a long time ('count'
is
> 28 bit).
> This counter keeps running, and each time it terminates, produces a pulse.
> This pulse is used to trigger the second counter, which typically runs for
> much less time ('count' is 8 bit). This counter produces output 1 while
it
> is counting, then returns to 0 until it is retriggered by the pulse from
the
> first counter.
> The whole design is synchronous (running of a single clock at 100 MHz),
> using Webpack on Spartan IIE.
>
> Question: how long must the pulse from the first clock be, to ensure that
it
> triggers the second clock? As I see it, if it is one clock cycle long,
then
> the second clock should trigger on the next clock rising edge (providing
the
> sum of clock propagation and the 2nd clock flip-flop setup is less than
one
> clock cycle)... but functionally the pulse will fall back at the moment it
> is triggered (one cycle later), so will only work if the hold time of the
> flip-flop is less than the clock propagation.
> Is this safe? Does the pulse need to be longer? Will the simulation
tools
> realise if there is a problem here?
>
> Many thanks
>
> Tom Derham
It is inherently safe in FPGA design as is all same-clock synchronous logic.
If you're using different clocks, phase shifted clocks, or discrete logic
devices with unusual hold requirements, it may not be a slam dunk.
- John_H
Article: 60774Even if it's a standard, it still is stupid. Stupidity has a tendency to be very long-lived. But let's hope that sanity will prevail, some day... Peter Alfke Simon Peacock wrote: > > I think that's because one of the standards counts transistors in its MTBF.. > so a PAL is more reliable than an FPGA but less reliable than an HC00. > > Simon > > "
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