Message-ID: <3BB77CC3.DBD58021@sympatico.ca> From: Eric X-Mailer: Mozilla 4.6 [en] (Win98; U) X-Accept-Language: en,fr-CA,fr-FR MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: future Xilinx products wish list ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 125 Date: Sun, 30 Sep 2001 16:12:51 -0400 NNTP-Posting-Host: 64.229.209.89 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1001880711 64.229.209.89 (Sun, 30 Sep 2001 16:11:51 EDT) NNTP-Posting-Date: Sun, 30 Sep 2001 16:11:51 EDT Organization: Bell Sympatico Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeeds.belnet.be!news.belnet.be!newsfeed.sovam.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10316 Hi, A recent thread (Programming flash connected to CPLD via JTAG) and the chicken & egg problems associated with SRAM based FPGA configuration remembered me that configuring Xilinx FPGA from standard bytewide memory was much more convenient with previous FPGA series, and some other previously available and useful functions were also lost for no apparent reasons. --- In xilinx's early days (XC2000 / XC3000) there was a "Master Parallel Mode" that allowed the FPGA to be configured directly from a standard bytewide Rom / Eprom / Flash. http://www.xilinx.com/partinfo/3000.pdf (page 25) Spartan II / Virtex also have a parallel mode, but only in the "slave" role, without the proper address generation logic (a simple binary counter in facts). Most of my apps have both a processor and a FPGA, and no being able to configure it directly from the same parallel flash that holds the processor's application increases the system's chip count / EMI / power consumption / cost in a very artificial and inefficient way. Namely, the 3 main ways to configure a Xilinx FPGA are : - use a serial config prom that's often more expensive and harder to find than the FPGA it configures. In systems that don't already use a bytewide Flash, cost and availability often make up for the few extra pins needed for the function. In system that already use a bytewide flash, configuration storage in Flash is either free or require the next bigger flash size, for an added cost often under 1$. - Add an address counter / flash interface CPLD between the Flash and the FPGA but that's a board space taking, cost increasing and often power hungry piece of silicon that's completely useless once the FPGA is configured. Also there is the "how to fill the flash ?" problem and then the "how to fill the flash in a reasonable time ?" problem that is even more difficult to solve. Have a look at the "Programming flash connected to CPLD via JTAG" thread for more informations on this problem. - put the FPGA out of the processor's data path so that it can start running even if the FPGA is not configured yet and configure it later (using software). That's usually what I end up doing, but it adds discrete glue logic and artificial complexities, and prevents the FPGA from being used in the processor's data path (memory management / bus demultiplexing, bus arbitration, Etc ...) since they must be functional before the FPGA is configured. Since putting the "Master Parallel Mode" back as a configuration option would add virtually no silicon area/cost to the FPGA (it's just a binary counter) I can't see any reason for not putting it back, except that it might hurt expensive serial proms sales. Few years ago, when FPGA were mostly used in projects where cost was not a real concern, adding the config prom was no big deal. Now that FPGA are used for more cost constrained applications (with the Spartan series), costs associated with configuration need to be reduced, and the return of the "Master Parallel Mode" would be the easiest way to do it. Also, sharing the configuration flash with a processor is a good way to allow processor software controlled FPGA configuration changes for late product differentiation / evolution / bug correction. This is not possible with OTP serial proms and require extra circuitry / software with reprogrammable serial proms. The other way around, it also allows the FPGA to program the bytewide flash containing it's own application configuration and the processor's program / data in system, using serial or JTAG configuration to serially load the FPGA with a flash programmer / JTAG (or serial) emulation configuration and then use it to program the flash. ------- While I'm at it, I also can't see why the configuration oscillator that was available for the user after configuration until Spartan is no more offered. Having an internal clock source (no matter how imprecise it was) was not only handy, but a very good way to add a watchdog to a processor based design, or a low power standby mode (put the main processor in clock stop mode and keep some background tasks going, such as keyboard scanning, analog voltage (ADC) monitoring or simply a periodical processor wake up) Now that this oscillator was enhanced to allow programmable frequency in master serial configuration mode, it would be even more useful. ------- Another option that existed with early FPGAs was the crystal oscillator. With new generation FPGAs supporting so many different IO standards, adding low gain inverter option on at least a pair of pins so that they can be used as a quartz oscillator would certainly be both easy and useful. http://www.xilinx.com/partinfo/3000.pdf (page 16) ------- Since I'm in a wish list, a device that I would really like to have in FPGAs and that would be useful in virtually all applications is a good programmable PLL frequency generator similar to this one : http://www.icst.com/pdf/ics3070102.pdf Clock generation nirvana would be (nearly !) attained if it could use a low power, low EMI, smallest size, very low cost 32768 Hz watch crystal as the reference. You can find here an example of such a design (page 44) : http://www.semiconductors.philips.com/acrobat/3070.pdf some Atmel ARM processors also use a 32768 hz crystal / PLL to generate their clock. Also, lowering the min. frequency of at least one of the DLLs from 25 Mhz to something around 12 Mhz would allow more choice for fundamental mode crystal oscillator frequencies (oscillators beyond 24 Mhz usually require 3rd overtone mode that's inherently less reliable, needs more parts including an inductor and have a longer startup time) as well as reduce power and EMI generation. ----------- I really hope to see the first 2 features back in newer FPGAs and the next 2 ones would add value for many applications at negligible cost. Am I the only one interested in these features, or would other users also like to see them in future Xilinx products ? regards, Eric. ###### From: John Larkin Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... Date: Sun, 30 Sep 2001 16:58:27 -0700 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3BB77CC3.DBD58021@sympatico.ca> X-Newsreader: Forte Agent 1.6/32.525 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: newsabuse@supernews.com Lines: 22 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!fr.clara.net!heighliner.fr.clara.net!news-feed.riddles.org.uk!sn-xit-03!sn-post-01!supernews.com!news.supernews.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10330 On Sun, 30 Sep 2001 16:12:51 -0400, Eric wrote: > >- put the FPGA out of the processor's data path so that it can start running >even if the FPGA is not configured yet and configure it later (using software). >That's usually what I end up doing, but it adds discrete glue logic and artificial >complexities, and prevents the FPGA from being used in the processor's data >path (memory management / bus demultiplexing, bus arbitration, Etc ...) since >they must be functional before the FPGA is configured. > I commonly hang a Xilinx FPGA right on my uP's data bus, and configure it serially in bit-bang mode after the proccessor is up and running, using three parallel port pins. The FPGA config pattern data is just built into the processor's EPROM code. The FPGA is tristated until it's configured... this works fine. John ###### From: sknapp@triscend.com (Steven K. Knapp) Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... Date: 30 Sep 2001 22:39:11 -0700 Organization: http://groups.google.com/ Lines: 71 Message-ID: References: <3BB77CC3.DBD58021@sympatico.ca> NNTP-Posting-Host: 148.63.91.238 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1001914751 20611 127.0.0.1 (1 Oct 2001 05:39:11 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 1 Oct 2001 05:39:11 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!4236096!news.imp.ch!psinet-eu-nl!newsfeeds.belnet.be!news.belnet.be!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10334 Just FYI. If you are using a processor plus FPGA or CPLD, you also might be interested in the Triscend Configurable System-on-Chip (CSoC) devices. The Triscend CSoC parts embed an industry-standard processor, peripherals, memory, a high-speed bus, and a block of LUT-based programmable logic, all in a single device. The CSoC device boots from a single external memory device, per your request. The boot PROM holds the configuration data for the embedded programmable logic plus the application program for the embedded processor. You can also download and debug the device directly via a JTAG port. There are two Triscend CSoC families available today--one based around the 8-bit 8051/8052 microcontroller and another based around the 32-bit ARM7TDMI RISC processor. There is more information at the following link. http://www.triscend.com/products The E5 family--based around the 8051--has both an internal ring oscillator and a crystal-oscillator amplifier that operates up to 40 MHz. The A7 family--ARM7TDMI-based--uses a 32.768 kHz watch crystal to synthesize system clock frequencies between 1 and 60 MHz. It too has an internal ring oscillator. Eric wrote in message news:<3BB77CC3.DBD58021@sympatico.ca>... [snip] > > --- > > In xilinx's early days (XC2000 / XC3000) there was a "Master Parallel Mode" > that allowed the FPGA to be configured directly from a standard bytewide > Rom / Eprom / Flash. > http://www.xilinx.com/partinfo/3000.pdf (page 25) > Spartan II / Virtex also have a parallel mode, but only in the "slave" role, > without the proper address generation logic (a simple binary counter in facts). > > Most of my apps have both a processor and a FPGA, and no being able > to configure it directly from the same parallel flash that holds the processor's > application increases the system's chip count / EMI / power consumption / cost > in a very artificial and inefficient way. > [snip] > > ------- > > Another option that existed with early FPGAs was the crystal oscillator. > With new generation FPGAs supporting so many different IO standards, > adding low gain inverter option on at least a pair of pins so that they > can be used as a quartz oscillator would certainly be both easy and useful. > > http://www.xilinx.com/partinfo/3000.pdf (page 16) > > ------- > > Since I'm in a wish list, a device that I would really like to have in > FPGAs and that would be useful in virtually all applications is a good > programmable PLL frequency generator similar to this one : > http://www.icst.com/pdf/ics3070102.pdf > Clock generation nirvana would be (nearly !) attained if it could use a > low power, low EMI, smallest size, very low cost 32768 Hz watch crystal > as the reference. > You can find here an example of such a design (page 44) : > http://www.semiconductors.philips.com/acrobat/3070.pdf > some Atmel ARM processors also use a 32768 hz crystal / PLL to generate > their clock. > [snip] ###### Message-ID: <3BB89E0E.D76A3B31@andraka.com> From: Ray Andraka Organization: Andraka Consulting Group, Inc X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... References: <3BB77CC3.DBD58021@sympatico.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 49 Date: Mon, 01 Oct 2001 16:46:47 GMT NNTP-Posting-Host: 24.13.238.93 X-Complaints-To: abuse@home.net X-Trace: news1.wwck1.ri.home.com 1001954807 24.13.238.93 (Mon, 01 Oct 2001 09:46:47 PDT) NNTP-Posting-Date: Mon, 01 Oct 2001 09:46:47 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.gtei.net!newshub2.home.com!news.home.com!news1.wwck1.ri.home.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10323 Steve, How big is your FPGA fabric these days (ie how many CLBs). Last I looked, you were using a rough equivalent of the xilinx 4K architecture. IIRC the equivalent device size was not very big, so it didn't meet the needs of something that needed alot of FPGA plus some microprocessor. What is the top of your line now? "Steven K. Knapp" wrote: > Just FYI. If you are using a processor plus FPGA or CPLD, you also > might be interested in the Triscend Configurable System-on-Chip (CSoC) > devices. The Triscend CSoC parts embed an industry-standard > processor, peripherals, memory, a high-speed bus, and a block of > LUT-based programmable logic, all in a single device. > > The CSoC device boots from a single external memory device, per your > request. The boot PROM holds the configuration data for the embedded > programmable logic plus the application program for the embedded > processor. You can also download and debug the device directly via a > JTAG port. > > There are two Triscend CSoC families available today--one based around > the 8-bit 8051/8052 microcontroller and another based around the > 32-bit ARM7TDMI RISC processor. There is more information at the > following link. > http://www.triscend.com/products > > The E5 family--based around the 8051--has both an internal ring > oscillator and a crystal-oscillator amplifier that operates up to 40 > MHz. > > The A7 family--ARM7TDMI-based--uses a 32.768 kHz watch crystal to > synthesize system clock frequencies between 1 and 60 MHz. It too has > an internal ring oscillator. > > -- --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, 1759 ###### Message-ID: <3BB933D7.2D9D3732@sympatico.ca> From: Eric X-Mailer: Mozilla 4.6 [en] (Win98; U) X-Accept-Language: en,fr-CA,fr-FR MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... References: <3BB77CC3.DBD58021@sympatico.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 55 Date: Mon, 01 Oct 2001 23:26:15 -0400 NNTP-Posting-Host: 64.229.200.35 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1001992834 64.229.200.35 (Mon, 01 Oct 2001 23:20:34 EDT) NNTP-Posting-Date: Mon, 01 Oct 2001 23:20:34 EDT Organization: Bell Sympatico Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.tele.dk!small.news.tele.dk!195.54.122.107!newsfeed1.bredband.com!bredband!newsfeed.sovam.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10347 Hi, John Larkin wrote: > I commonly hang a Xilinx FPGA right on my uP's data bus, and configure > it serially in bit-bang mode after the proccessor is up and running, > using three parallel port pins. The FPGA config pattern data is just > built into the processor's EPROM code. The FPGA is tristated until > it's configured... this works fine. Yes, it's a good way to go, but it only works if the FPGA is not part of the processor's data / address / memory selection or management path. My app uses a 16 bits data bus processor connected to a 8 bit Ram/Flash combo chip (FYI, the processor is Intel 80L186EB16, the combochip is SST's 31LF041 and the FPGA is XC2S50 / XC2S100 in TQ144 package). Since the Combomemory is much faster than the processor, I can keep the board space / EMI / cost down by implementing a 8 / 16 bits bus translator (properly realigns data in single byte read/writes and does 2 successive read/ writes for word accesses) in the spartan II chip that would be transparent to the processor, and benefit from the added speed (compared to the 8 bit external bus version of the processor) at virtually no cost (uses very few CLBs and 11 additional IOPads). However, there is a chicken and egg situation here since the processor can't access it's pogram memory until the FPGA is configured, and the FPGA needs the processor to be configured. Same situation is also true in designs that use a SDRAM as the processor's main memory and implement the SDRAM controller in the FPGA. In these apps (generally 32 bits), you typically need a 32 bits (or at least 16 with some of them) boot rom to feed the processor. A CPLD can be used to "patch" the sitution, but it's much less elegant than if the FPGA itself could generate the address bits (and you need an expensive Coolrunner unless loosing 20 mA to power a CPLD that's useless most of the time is ok). This compromise CPLD does not even save FPGA pins, since all the Flash pins must be connected to the FPGA to allow initial flash In system Programming (programming the boot software before memory is mounted using a device programmer with these tiny 0.5mm lead pitch TSOP chips is asking for trouble) In this particular design, I'll probably end up with either a XCR3032 or a PIC16C55 processor used as an address counter configuring the FPGA in parallel slave mode but that's an inelegant quick fix that I would gladly remove in a next version if, let's say Spartan III, includes the Master Parallel mode just like it was in the old 2000 and 3000 series. regards, Eric. ###### Message-ID: <3BB95047.63B89D05@sympatico.ca> From: Eric X-Mailer: Mozilla 4.6 [en] (Win98; U) X-Accept-Language: en,fr-CA,fr-FR MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... References: <3BB77CC3.DBD58021@sympatico.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 51 Date: Tue, 02 Oct 2001 01:27:35 -0400 NNTP-Posting-Host: 64.229.200.35 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1002000388 64.229.200.35 (Tue, 02 Oct 2001 01:26:28 EDT) NNTP-Posting-Date: Tue, 02 Oct 2001 01:26:28 EDT Organization: Bell Sympatico Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.tele.dk!small.news.tele.dk!195.54.122.107!newsfeed1.bredband.com!bredband!newsfeed.sovam.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10346 Hi, These chips are interresting to say the least, however, I need 16 bit x86 architecture compatibility. 8051/ARM users who also need a small / medium FPGA certainly should explore them. The more you integrate different unrelated devices on the same chip, the more variants you need to have to fit most users needs in a cost effective way. Whenever the limits for such all-in-one chips are exceeded, I believe there certainly also is a huge market for standard "FPGA only" chips that are optimized for a direct (without any glue logic) connection to commonly used processors that can share the nonvolatile memory to form highly featured cost effective trios. All the little changes that were in my wish list are oriented toward that goal. On a non technical point of view, this "intrusion" of FPGAs closer to commonly used microcontrollers would certainly attract many designers who still see them as exotic & hard to use high end parts. regards, Eric. "Steven K. Knapp" wrote: > Just FYI. If you are using a processor plus FPGA or CPLD, you also > might be interested in the Triscend Configurable System-on-Chip (CSoC) > devices. The Triscend CSoC parts embed an industry-standard > processor, peripherals, memory, a high-speed bus, and a block of > LUT-based programmable logic, all in a single device. > > The CSoC device boots from a single external memory device, per your > request. The boot PROM holds the configuration data for the embedded > programmable logic plus the application program for the embedded > processor. You can also download and debug the device directly via a > JTAG port. > > There are two Triscend CSoC families available today--one based around > the 8-bit 8051/8052 microcontroller and another based around the > 32-bit ARM7TDMI RISC processor. There is more information at the > following link. > http://www.triscend.com/products > > The E5 family--based around the 8051--has both an internal ring > oscillator and a crystal-oscillator amplifier that operates up to 40 > MHz. > > The A7 family--ARM7TDMI-based--uses a 32.768 kHz watch crystal to > synthesize system clock frequencies between 1 and 60 MHz. It too has > an internal ring oscillator. ###### From: sknapp@triscend.com (Steven K. Knapp) Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... Date: 2 Oct 2001 11:11:11 -0700 Organization: http://groups.google.com/ Lines: 96 Message-ID: References: <3BB77CC3.DBD58021@sympatico.ca> <3BB89E0E.D76A3B31@andraka.com> NNTP-Posting-Host: 63.87.30.34 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1002046272 18523 127.0.0.1 (2 Oct 2001 18:11:12 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 2 Oct 2001 18:11:12 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.tele.dk!small.news.tele.dk!128.230.129.106!news.maxwell.syr.edu!feeder.qis.net!sn-xit-02!supernews.com!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10365 You are correct that the Triscend CSoC devices are "system heavy" rather than "programmable logic heavy." These devices focus on on integrating a complete system, leveraging programmable logic as the flexible interface to the rest of the world. In no way do CSoC devices replace high-end FPGAs unless you plan on creating a sophisticated processor-based system, complete with peripherals. In fact, some CSoC users also have one or more large FPGAs on each board. The largest commercially available Triscend CSoC device has 2,048 cells with 3,200 cells coming soon. Each cell is a 4-input LUT plus flip-flop. The primary difference between a Triscend CSoC logic cell and FPGA or CPLD logic is that the CSoC logic cell intimately connects to the internal system bus, with predicatable timing. Similarly there is built-in address decoding and DMA services within the CSoC logic matrix. Furthermore, every LUT and flip-flop output can be probed in real-time via JTAG for easy debugging. CSoC are best in applciations that currently use a processor + programmable logic, a common combination in many embedded applications. There are a variety of problems that are solved much easier with a processor than attempting to implement it in hardware. The opposite is also certainly true. CSoC devices provide the designer with the opportunity to easily optimize the hardware/software trade-off. To answer your question about "top of the line", the currently available top of the line is the TA7S20 which has the following features. Larger devices are due out next year. * ARM7TDMI 32-bit RISC CPU * 8K-byte unified cache * 16K-byte internal single-cycle RAM (8K available as trace buffer) * Split bus architecture supporting up to 455 MB/s transfers * 4-channel DMA supporting linked-list, fly-by performance * Two 16C450/550-style UARTs * Two 16-bit timers * 32-bit watchdog timer * Hardware breakpoint, tracepoint * JTAG debugger interface * Flash memory interface * SDRAM memory interface * 16-input interrupt controller * 2,048 logic cells (approximately 25K gates) * Up to 190 user-defined I/O pins http://www.triscend.com/products/indexA7.html Ray Andraka wrote in message news:<3BB89E0E.D76A3B31@andraka.com>... > Steve, > > How big is your FPGA fabric these days (ie how many CLBs). Last I looked, you were using a > rough equivalent of the xilinx 4K architecture. IIRC the equivalent device size was not very > big, so it didn't meet the needs of something that needed alot of FPGA plus some > microprocessor. What is the top of your line now? > > "Steven K. Knapp" wrote: > > > Just FYI. If you are using a processor plus FPGA or CPLD, you also > > might be interested in the Triscend Configurable System-on-Chip (CSoC) > > devices. The Triscend CSoC parts embed an industry-standard > > processor, peripherals, memory, a high-speed bus, and a block of > > LUT-based programmable logic, all in a single device. > > > > The CSoC device boots from a single external memory device, per your > > request. The boot PROM holds the configuration data for the embedded > > programmable logic plus the application program for the embedded > > processor. You can also download and debug the device directly via a > > JTAG port. > > > > There are two Triscend CSoC families available today--one based around > > the 8-bit 8051/8052 microcontroller and another based around the > > 32-bit ARM7TDMI RISC processor. There is more information at the > > following link. > > http://www.triscend.com/products > > > > The E5 family--based around the 8051--has both an internal ring > > oscillator and a crystal-oscillator amplifier that operates up to 40 > > MHz. > > > > The A7 family--ARM7TDMI-based--uses a 32.768 kHz watch crystal to > > synthesize system clock frequencies between 1 and 60 MHz. It too has > > an internal ring oscillator. > > > > > > -- > --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, 1759 ###### From: "Geoffrey G. Rochat" Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... Date: Sun, 30 Sep 2001 22:57:29 -0400 Organization: WWW.US.INTER.NET Lines: 48 Message-ID: <9p8lg2$on2$1@news-central.tiac.net> References: <3BB77CC3.DBD58021@sympatico.ca> NNTP-Posting-Host: 65.90.45.79 X-Trace: news-central.tiac.net 1001904451 25314 65.90.45.79 (1 Oct 2001 02:47:31 GMT) X-Complaints-To: abuse@us.inter.net NNTP-Posting-Date: Mon, 1 Oct 2001 02:47:31 +0000 (UTC) X-Newsreader: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!t-online.de!colt.net!news.maxwell.syr.edu!news-peer1.tiac.net!posterchild1.tiac.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10443 >On Sun, 30 Sep 2001 16:12:51 -0400, Eric >wrote: > >> >>- put the FPGA out of the processor's data path so that it can start running >>even if the FPGA is not configured yet and configure it later (using software). >>That's usually what I end up doing, but it adds discrete glue logic and artificial >>complexities, and prevents the FPGA from being used in the processor's data >>path (memory management / bus demultiplexing, bus arbitration, Etc ...) since >>they must be functional before the FPGA is configured. >> > >I commonly hang a Xilinx FPGA right on my uP's data bus, and configure >it serially in bit-bang mode after the proccessor is up and running, >using three parallel port pins. The FPGA config pattern data is just >built into the processor's EPROM code. The FPGA is tristated until >it's configured... this works fine. > The problem here is that if the FPGA is a critical system chip such that the basic microprocessor system cannot run without it (if, for example, the FPGA does all address decoding or is the system memory controller or contains all the peripherals), one cannot boot the FPGA with a processor that requires the FPGA to be running before it can function. I ran into a client who, through inattention, had backed themselves into exactly this corner about six months ago, and the only way out was a costly board respin to add some non-volatile logic to the board. (My having to deliver the news to the client, after the fact, that they had made such a serious conceptual mistake in their initial design was not taken kindly...) This sort of system requirement is not at all uncommon in embedded work. Back in XC4000 days I frequently would have the FPGA boot itself first out of the same EPROM that the microprocessor would then use for its own boot. Xilinx was very helpful here in providing master parallel modes that booted from the bottom of memory up or from the top of memory down so as to keep the FPGA and CPU boot code separate, and the HDC and LDC pins held high and low during configuration were handy ways to keep the microprocessor reset during FPGA self-boot. I think Xilinx made a mistake by not continuing to provide these features in their newer parts. I must say that I agree with the original poster on just about every point made. ###### Reply-To: "Rob Finch" From: "Rob Finch" Newsgroups: comp.arch.fpga References: <3BB77CC3.DBD58021@sympatico.ca> <9p8lg2$on2$1@news-central.tiac.net> Subject: Re: future Xilinx products wish list ... Lines: 15 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Sun, 7 Oct 2001 23:14:33 -0400 NNTP-Posting-Host: 64.229.13.147 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1002510713 64.229.13.147 (Sun, 07 Oct 2001 23:11:53 EDT) NNTP-Posting-Date: Sun, 07 Oct 2001 23:11:53 EDT Organization: Bell Sympatico Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sunqbc.risq.qc.ca!torn!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10459 I agree with the original poster's comments. Also, it would be nice if the 'done' signal were available to a user programmable pin in addition to it's regular pin. (Perhaps it could be tri-state isolated from the user pin after configuration). That way, it could be used in address decoding for an eprom shared between configuration bits and microprocessor code. Might save some external gates. Rob http://www.birdcomputer.ca/ ###### Message-ID: <3BC1202D.BEAD366A@earthlink.net> From: Peter Alfke Reply-To: palfke@earthlink.net X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... References: <3BB77CC3.DBD58021@sympatico.ca> <9p8lg2$on2$1@news-central.tiac.net> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Lines: 20 Date: Mon, 08 Oct 2001 03:40:37 GMT NNTP-Posting-Host: 216.244.43.236 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 1002512437 216.244.43.236 (Sun, 07 Oct 2001 20:40:37 PDT) NNTP-Posting-Date: Sun, 07 Oct 2001 20:40:37 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Sun, 07 Oct 2001 20:37:02 PDT (newsmaster1.prod.itd.earthlink.net) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeeds.belnet.be!news.belnet.be!feed2.onemain.com!feed1.onemain.com!feed1.newsreader.com!netnews.com!xfer02.netnews.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10450 Why don't you use "any" pin, rely on the fact that it is 3-stated with weak pull-up during configuration, and make it active Low after configuration. Maybe add a 1 kilohm pull-up... Or am I missing something ? Peter Alfke Rob Finch wrote: > I agree with the original poster's comments. > > Also, it would be nice if the 'done' signal were available to a user > programmable pin in addition to it's regular pin. (Perhaps it could be > tri-state isolated from the user pin after configuration). That way, it > could be used in address decoding for an eprom shared between configuration > bits and microprocessor code. Might save some external gates. > > Rob > http://www.birdcomputer.ca/ ###### Message-ID: <3BC1CA87.BD87F36E@sympatico.ca> From: Eric X-Mailer: Mozilla 4.6 [en] (Win98; U) X-Accept-Language: en,fr-CA,fr-FR MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... References: <3BB77CC3.DBD58021@sympatico.ca> <9p8lg2$on2$1@news-central.tiac.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Lines: 87 Date: Mon, 08 Oct 2001 11:47:20 -0400 NNTP-Posting-Host: 64.229.202.223 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1002555965 64.229.202.223 (Mon, 08 Oct 2001 11:46:05 EDT) NNTP-Posting-Date: Mon, 08 Oct 2001 11:46:05 EDT Organization: Bell Sympatico Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!sunqbc.risq.qc.ca!torn!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10448 Hi, Talking about pins that could be used for user IO after configuration, there is : - M0 M1 M2 : According to the data sheet (Spartan II, page 13), the state of these pins is only required to be valid on the Low to High transition of INIT (not very clear, would seem more logical if they had a setup time). No matter the exact timing, they obviously are only required at a precise point during configuration and are useless except at that time. After configuration, I see no reason why they could not be used as IO. - HSWAP_EN (Virtex II) Same as M0 .. M2 - CCLK : Obviously, it have no function after configuration is complete, and in most apps, I end up connecting it to another IO pin (when configuration is bit banged by a processor, CCLK is usually connected to some kind of address decoding, and it is used after configuration as a "Chip Select" input). Here too, I can't see any reason for not using it as an IO - TDI TDO TMS TCK In previous series (at least Spartan), these could be used as IO if the boundary scan function was not required. I miss these 4 pins (even if I screwed up once with them and could not properly configure the chip because of random data being fed to them). With proper care, they are great as IO too. - DONE. Here too, as Rob Finch said, I can't see why it's not a user IO after configuration. - PROGRAM. Obviously, this pin can't be used as an input, but it could be used as an Open drain output. Hiz : Well, does nothing ... Low : If properly latched / delayed /cleared, can be used to trigger self reconfiguration. This self reset can be used to restart without using external logic when a faulty condition is detected (or whenever the designer want to reboot the device). ------ Also, as Geoffrey G. Rochat stated, I miss both HDC and LDC pins too. Another pin that might be very useful (if Master Parallel mode goes back) would be a "TDC" pin that would toggle during configuration. Here's how it would work : Initially, it would be a high impedance (or high level) pin, but if the configuration fail, it would go to "0" and start toggling each time the configuration fails. The use would be to connect it to an address pin of the configuration ROM in systems that require the FPGA to start even in case of a failed configuration download. That way, the FPGA would attempt to start from the potentially corrupted configuration data, detect the bad CRC and restart from the original "fail-safe" configuration. This fail-safe mode is needed as soon as a potentially unreliable update must be made (such as remote/modem update), at the expense of a doubled configuration rom size. In applications that don't need the functions, it's very rare not to be able to find any pin in the design that can be either pulled high, or low, or toggled during configuration with no adverse effect. ------ These changes would help mostly with low pin count packages where these ten user IO pins could certainly be put to good use, and since this is all programmable, it would all be backward compatible (except HDC / LDC) for users who don't need them. Also, not loosing pins used for configuration would allow for even more configuration options without loosing more user pins (and/or increasing the number of Power/GND pairs without decreasing the useable pin count). Éric. --------------------------------- Rob Finch wrote: > I agree with the original poster's comments. > > Also, it would be nice if the 'done' signal were available to a user > programmable pin in addition to it's regular pin. (Perhaps it could be > tri-state isolated from the user pin after configuration). That way, it > could be used in address decoding for an eprom shared between configuration > bits and microprocessor code. Might save some external gates. > > Rob > http://www.birdcomputer.ca/ ###### From: z80@ds2.com (Peter) Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... Date: Fri, 12 Oct 2001 20:24:13 +0100 Organization: - Lines: 15 Message-ID: References: <3BB77CC3.DBD58021@sympatico.ca> <9p8lg2$on2$1@news-central.tiac.net> NNTP-Posting-Host: dialup-26-26.netcomuk.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: taliesin2.netcom.net.uk 1002914757 9829 194.42.235.26 (12 Oct 2001 19:25:57 GMT) X-Complaints-To: abuse@corp.netcom.net.uk NNTP-Posting-Date: Fri, 12 Oct 2001 19:25:57 +0000 (UTC) X-Newsreader: Forte Agent 1.8/32.548 X-No-Archive: yes Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!t-online.de!colt.net!shale.ftech.net!news.ftech.net!diablo.netcom.net.uk!netcom.net.uk!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10525 The one wish I had regarding these parts was the CLK input to have a schmitt trigger on it. I have designed several complicated waveform generators, each containing 32 or 64 FPGAs (XC3k and XC4k devices). I had enormous problems distributing the config clock around these boards, which were IBM PC full-size with devices both sides. Loads of decoupling, 6 layers (incl. VCC and GND planes), very careful tracking, you name it. The config clock input is extremely sensitive to risetime. Too slow, it won't work, too fast and it cannot be distributed to many devices. I vaguely recall that it has to be faster than 20ns, and driving it from a 74HC output was too slow. ###### From: Theron Hicks Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... Date: Fri, 12 Oct 2001 16:20:08 -0400 Organization: Michigan State University Lines: 8 Message-ID: <3BC75078.85FABF7C@egr.msu.edu> References: <3BB77CC3.DBD58021@sympatico.ca> <9p8lg2$on2$1@news-central.tiac.net> NNTP-Posting-Host: dfti.egr.msu.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!t-online.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.stanford.edu!info1.fnal.gov!nntp.upenn.edu!msunews!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10550 I would think that a built-in crystal oscillator port would be a great option. Also, I personally would like to see real LVPECL (i.e.suitable for single ended LVPECL inputs) with real LVPECL levels. Also packages with pins (SMT pins are OK but not those ball grid arrays) for those who are using FPGA's as a short production run (read PROTOTYPE) device. Theron Hicks ###### From: Tom Burgess Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... Date: Fri, 12 Oct 2001 14:38:41 -0700 Organization: National Research Council of Canada Lines: 33 Message-ID: <3BC762E1.666F99F6@hia.nrc.ca> References: <3BB77CC3.DBD58021@sympatico.ca> <9p8lg2$on2$1@news-central.tiac.net> <3BC75078.85FABF7C@egr.msu.edu> NNTP-Posting-Host: puppis.drao.nrc.ca Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: moonstone.imsb.nrc.ca 1002922721 17119 192.139.21.115 (12 Oct 2001 21:38:41 GMT) X-Complaints-To: news@moonstone.imsb.nrc.ca NNTP-Posting-Date: 12 Oct 2001 21:38:41 GMT X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,pdf Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cyclone.bc.net!torn!moonstone.imsb.nrc.ca!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10524 Yes to all of those - I would love to see the Virtex programmable termination feature (I forget the marketing name) enhanced to support - WITHOUT external resistive dividers - LVDS and PECL I/O, and to support programmable DIFFERENTIAL termination as well. Well, I can wish, can't I? For prototypes, and for some types of production, I would be content with being able to buy BGAs from Xilinx or via distros pre-soldered to BGA-socket/adapter thingies such as http://www.mill-max.com/products/bga/bga.htm rather than having to deal with getting this done myself. This would be an optional service that could simplify things for a lot of people, I think. To solve the slow global reset problem, how about circuitry on each clock buffer that could disable it during reset, then synchronously re-enable it N clocks after end of reset, where N is programmable (0 for no delay), up to some reasonable maximum sufficient to accomodate the reset recovery time and max clock rate. Or some simpler scheme that would accomplish the same thing. Theron Hicks wrote: > > I would think that a built-in crystal oscillator port would be a great > option. Also, I personally would like to see real LVPECL (i.e.suitable > for single ended LVPECL inputs) with real LVPECL levels. Also packages > with pins (SMT pins are OK but not those ball grid arrays) for those who > are using FPGA's as a short production run (read PROTOTYPE) device. > > Theron Hicks -- Tom Burgess Digital Engineer Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3 ###### From: "Tim" Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... Date: Sat, 13 Oct 2001 02:02:45 +0100 Message-ID: <1002936111.19967.1.nnrp-02.9e9832fa@news.demon.co.uk> References: <3BB77CC3.DBD58021@sympatico.ca> <9p8lg2$on2$1@news-central.tiac.net> <3BC1CA87.BD87F36E@sympatico.ca> NNTP-Posting-Host: tile.demon.co.uk X-NNTP-Posting-Host: tile.demon.co.uk:158.152.50.250 X-Trace: news.demon.co.uk 1002936111 nnrp-02:19967 NO-IDENT tile.demon.co.uk:158.152.50.250 X-Complaints-To: abuse@demon.net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Lines: 131 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!newsfeed.icl.net!dispose.news.demon.net!news.demon.co.uk!demon!tile.demon.co.uk!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10650 Another point of view... I disagree on the dual-use of pins. Please put ALL the config, etc, pins on the VCCAUX supply. I.E. on non-banked balls. I guess we could also have an option to connect some of these to the logic matrix. The V2 lineup is so much better than the 4K/Virtex arrangements, but it is still annoying to have config spread between VCCAUX and whatever voltages banks 4 and 5 are set at. Maybe the long term plan is to configure/readback the big stuff via JTAG only - the details of ROM handling can be farmed out to a PAL. "Eric" wrote in message news:3BC1CA87.BD87F36E@sympatico.ca... > Hi, > > Talking about pins that could be used for user IO after configuration, there is : > > - M0 M1 M2 : According to the data sheet (Spartan II, page 13), the state > of these pins is only required to be valid on the Low to High transition of INIT > (not very clear, would seem more logical if they had a setup time). > No matter the exact timing, they obviously are only required at a precise point > during configuration and are useless except at that time. > After configuration, I see no reason why they could not be used as IO. > > - HSWAP_EN (Virtex II) > Same as M0 .. M2 > > - CCLK : Obviously, it have no function after configuration is complete, and in most > apps, I end up connecting it to another IO pin (when configuration is bit banged by a > processor, CCLK is usually connected to some kind of address decoding, and it is > used after configuration as a "Chip Select" input). > Here too, I can't see any reason for not using it as an IO > > - TDI TDO TMS TCK > In previous series (at least Spartan), these could be used as IO if the boundary scan > function was not required. I miss these 4 pins (even if I screwed up once with them > and could not properly configure the chip because of random data being fed to them). > With proper care, they are great as IO too. > > - DONE. > Here too, as Rob Finch said, I can't see why it's not a user IO after configuration. > > - PROGRAM. > > Obviously, this pin can't be used as an input, but it could be used as an Open drain output. > Hiz : Well, does nothing ... > Low : If properly latched / delayed /cleared, can be used to trigger self reconfiguration. > This self reset can be used to restart without using external logic when a faulty condition > is detected (or whenever the designer want to reboot the device). > > ------ > > Also, as Geoffrey G. Rochat stated, I miss both HDC and LDC pins too. > > Another pin that might be very useful (if Master Parallel mode goes back) would be a "TDC" > pin that would toggle during configuration. > Here's how it would work : > Initially, it would be a high impedance (or high level) pin, but if the configuration fail, > it would go to "0" and start toggling each time the configuration fails. > > The use would be to connect it to an address pin of the configuration ROM in systems that > require the FPGA to start even in case of a failed configuration download. > > That way, the FPGA would attempt to start from the potentially corrupted configuration > data, detect the bad CRC and restart from the original "fail-safe" configuration. > > This fail-safe mode is needed as soon as a potentially unreliable update must be made > (such as remote/modem update), at the expense of a doubled configuration rom size. > > In applications that don't need the functions, it's very rare not to be able to find > any pin in the design that can be either pulled high, or low, or toggled during > configuration with no adverse effect. > > ------ > > These changes would help mostly with low pin count packages where these ten user IO pins > could certainly be put to good use, and since this is all programmable, it would all be > backward compatible (except HDC / LDC) for users who don't need them. > > Also, not loosing pins used for configuration would allow for even more configuration options > without loosing more user pins (and/or increasing the number of Power/GND pairs without > decreasing the useable pin count). > > Éric. > > --------------------------------- > > Rob Finch wrote: > > > I agree with the original poster's comments. > > > > Also, it would be nice if the 'done' signal were available to a user > > programmable pin in addition to it's regular pin. (Perhaps it could be > > tri-state isolated from the user pin after configuration). That way, it > > could be used in address decoding for an eprom shared between configuration > > bits and microprocessor code. Might save some external gates. > > > > Rob > > http://www.birdcomputer.ca/ > ###### Message-ID: <3BC7A82D.C04A5054@earthlink.net> From: Peter Alfke Reply-To: palfke@earthlink.net X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... References: <3BB77CC3.DBD58021@sympatico.ca> <9p8lg2$on2$1@news-central.tiac.net> <3BC75078.85FABF7C@egr.msu.edu> <3BC762E1.666F99F6@hia.nrc.ca> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Lines: 21 Date: Sat, 13 Oct 2001 02:34:26 GMT NNTP-Posting-Host: 209.179.194.215 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 1002940466 209.179.194.215 (Fri, 12 Oct 2001 19:34:26 PDT) NNTP-Posting-Date: Fri, 12 Oct 2001 19:34:26 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Fri, 12 Oct 2001 19:30:48 PDT (newsmaster1.prod.itd.earthlink.net) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.direct.ca!look.ca!newsfeed1.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10575 Tom Burgess wrote: To solve the slow global reset problem, how about circuitry on each clock buffer that > could disable it during reset, then synchronously re-enable it N clocks after > end of reset, where N is programmable (0 for no delay), up to some reasonable maximum > sufficient to accomodate the reset recovery time and max clock rate. Or some simpler > scheme that would accomplish the same thing. You have that capabilty, kind of, today in Virtex-II, where each clock buffer has an enable input. What's missing is a timing circuit that blocks the clock appropriately. Read the description of the BUFGCE in the newest version of the data sheet that goes on the web this coming week ( and also to the printer soon thereafter) Peter Alfke, Xilinx Applications > > > ###### From: hamish@cloud.net.au Subject: Re: future Xilinx products wish list ... Newsgroups: comp.arch.fpga References: <3BB77CC3.DBD58021@sympatico.ca> <9p8lg2$on2$1@news-central.tiac.net> <3BC1CA87.BD87F36E@sympatico.ca> <1002936111.19967.1.nnrp-02.9e9832fa@news.demon.co.uk> User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (Linux/2.2.18 (i586)) Lines: 10 Message-ID: Date: Sat, 13 Oct 2001 06:47:50 GMT NNTP-Posting-Host: 203.164.64.6 X-Complaints-To: abuse@optushome.com.au X-Trace: news1.rdc1.nsw.optushome.com.au 1002955670 203.164.64.6 (Sat, 13 Oct 2001 16:47:50 EST) NNTP-Posting-Date: Sat, 13 Oct 2001 16:47:50 EST Organization: @Home Network Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!t-online.de!nntp-relay.ihug.net!newsfeeds.ihug.co.nz!ihug.co.nz!news.xtra.co.nz!news.mel.connect.com.au!newshub1.rdc1.nsw.optushome.com.au!news1.rdc1.nsw.optushome.com.au.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10561 Tim wrote: > Maybe the long term plan is to configure/readback the big stuff > via JTAG only - the details of ROM handling can be farmed out to a > PAL. Won't that be painfully slow for large devices? Hamish -- Hamish Moffatt VK3SB ###### Message-ID: <3BC7F1FC.571FAE30@algor.co.uk> From: Rick Filipkiewicz X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... References: <3BB77CC3.DBD58021@sympatico.ca> <9p8lg2$on2$1@news-central.tiac.net> <3BC75078.85FABF7C@egr.msu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Algorithmics Ltd. Cache-Post-Path: mudchute.algor.co.uk!unknown@rfhome.algor.co.uk X-Cache: nntpcache 2.4.0b2 (see http://www.nntpcache.org/) Lines: 19 Date: Sat, 13 Oct 2001 08:49:16 +0100 NNTP-Posting-Host: 62.254.210.251 X-Complaints-To: abuse@ntlworld.com X-Trace: news6-win.server.ntlworld.com 1002959364 62.254.210.251 (Sat, 13 Oct 2001 08:49:24 BST) NNTP-Posting-Date: Sat, 13 Oct 2001 08:49:24 BST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!t-online.de!colt.net!dispose.news.demon.net!demon!btnet-peer0!btnet!news5-gui.server.ntli.net!ntli.net!news6-win.server.ntlworld.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10547 Theron Hicks wrote: > I would think that a built-in crystal oscillator port would be a great > option. Also, I personally would like to see real LVPECL (i.e.suitable > for single ended LVPECL inputs) with real LVPECL levels. Also packages > with pins (SMT pins are OK but not those ball grid arrays) for those who > are using FPGA's as a short production run (read PROTOTYPE) device. > > Theron Hicks While we're on the subject of what Austin Lesea calls the V-3 hopper: Why not allow the drive strengths of the LVTTL/LVCMOS pins to be dynamically configurable so I can set my DRAM outputs dependent on how many, how big DIMMs are actually populated ? ###### From: "Tim" Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... Date: Sat, 13 Oct 2001 23:38:41 +0100 Message-ID: <1003014453.18501.1.nnrp-10.9e9832fa@news.demon.co.uk> References: <3BB77CC3.DBD58021@sympatico.ca> <9p8lg2$on2$1@news-central.tiac.net> <3BC1CA87.BD87F36E@sympatico.ca> <1002936111.19967.1.nnrp-02.9e9832fa@news.demon.co.uk> NNTP-Posting-Host: tile.demon.co.uk X-NNTP-Posting-Host: tile.demon.co.uk:158.152.50.250 X-Trace: news.demon.co.uk 1003014453 nnrp-10:18501 NO-IDENT tile.demon.co.uk:158.152.50.250 X-Complaints-To: abuse@demon.net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Lines: 21 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!uni-erlangen.de!news-nue1.dfn.de!newsfeed.r-kom.de!news0.de.colt.net!colt.net!dispose.news.demon.net!news.demon.co.uk!demon!tile.demon.co.uk!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10647 wrote > Tim wrote: > > Maybe the long term plan is to configure/readback the big stuff > > via JTAG only - the details of ROM handling can be farmed out to a > > PAL. > > Won't that be painfully slow for large devices? I guess. For the XC2V10000 the times work out as JTAG 1000ms (33MHz, 1-bit) Slave Serial 500ms (66MHz, 1-bit) SelectMap 60ms (66MHz, 8-bit) Since this is a high-speed serial world, and JTAG is usually limited to <50MHz (33MHz on Virtex) the future is presumably a smart JTAG extension. ###### Message-ID: <3BC911E3.1D2F5F5D@sympatico.ca> From: Eric X-Mailer: Mozilla 4.6 [en] (Win98; U) X-Accept-Language: en,fr-CA,fr-FR MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... References: <3BB77CC3.DBD58021@sympatico.ca> <9p8lg2$on2$1@news-central.tiac.net> <3BC1CA87.BD87F36E@sympatico.ca> <1002936111.19967.1.nnrp-02.9e9832fa@news.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 71 Date: Sun, 14 Oct 2001 00:17:39 -0400 NNTP-Posting-Host: 64.229.210.137 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1003032627 64.229.210.137 (Sun, 14 Oct 2001 00:10:27 EDT) NNTP-Posting-Date: Sun, 14 Oct 2001 00:10:27 EDT Organization: Bell Sympatico Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!sunqbc.risq.qc.ca!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10571 Hi, Tim wrote: > Another point of view... > > I disagree on the dual-use of pins. Could you explain why you disagree ? What kind of problem would it create for your app ? > Please put ALL the config, etc, > pins on the VCCAUX supply. Here too, it would be better if you could explain why. > I.E. on non-banked balls. Maybe I miss something here, but I really can't see why it could be a problem that D0-D7 and other signals are part of a IO bank as they are now. With the selectMap mode, you can keep them dedicated if you need to (they call it the "persist" option) so you get the best of both worlds. > I guess we could > also have an option to connect some of these to the logic matrix. The > V2 lineup is so much better than the 4K/Virtex arrangements, but it is > still annoying to have config spread between VCCAUX and whatever > voltages banks 4 and 5 are set at. Maybe all the pins that are already dual use would do better if they were grouped on a single or a separate bank. However, I don't see where the problem is for you since you seem to to configuration through JTAG and you don't use these pin's alternate function. > > Maybe the long term plan is to configure/readback the big stuff > via JTAG only - It's not because you don't use other configuration methods that they're useless. Also, as Hamish Moffatt wrote, JTAG speed is not too fast. SelectMap is around 16x faster. Should xilinx forget about Jtag and promote SelectMap as the only way to configure / readback an FPGA ? Certainly not ! Both are possible, choice is yours. > the details of ROM handling can be farmed out to a > PAL. Requiring an added, (soon to be obsolete) PAL chip where the FPGA could do it at no extra cost and without any consequences for other users escapes me (Am I missing a major drawback here ?). Similarly, the details of proper signal termination can be farmed out to a bunch of discrete resistors. However, Virtex II integrates the function on chip and users who need it welcome this added function. Others simply don't use it. The most important question here is whenever there is enough demand for that parallel master mode with an added address generation counter feature. I think there is, mostly for system that closely integrate processors and FPGAs, and also for systems that need large / fast reprogrammable configuration memory (an XCV2600E requires 4x XC18V04 while a single, standard flash rom such as this one: http://www.ssti.com/products/39lf_vf080_016.html would do, up to a XCV3200E ). One thing that's important is that if any of these enhancements are made, they should be transparent for users who don't need them. regards, Eric. ###### From: hamish@cloud.net.au Subject: Re: future Xilinx products wish list ... Newsgroups: comp.arch.fpga References: <3BB77CC3.DBD58021@sympatico.ca> <9p8lg2$on2$1@news-central.tiac.net> <3BC1CA87.BD87F36E@sympatico.ca> <1002936111.19967.1.nnrp-02.9e9832fa@news.demon.co.uk> <1003014453.18501.1.nnrp-10.9e9832fa@news.demon.co.uk> User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (Linux/2.2.18 (i586)) Lines: 17 Message-ID: Date: Sun, 14 Oct 2001 07:22:09 GMT NNTP-Posting-Host: 203.164.64.6 X-Complaints-To: abuse@optushome.com.au X-Trace: news1.rdc1.nsw.optushome.com.au 1003044129 203.164.64.6 (Sun, 14 Oct 2001 17:22:09 EST) NNTP-Posting-Date: Sun, 14 Oct 2001 17:22:09 EST Organization: @Home Network Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!news1.optus.net.au!optus!newshub1.rdc1.nsw.optushome.com.au!news1.rdc1.nsw.optushome.com.au.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10559 Tim wrote: > wrote >> Won't that be painfully slow for large devices? > I guess. For the XC2V10000 the times work out as > JTAG 1000ms (33MHz, 1-bit) > Slave Serial 500ms (66MHz, 1-bit) > SelectMap 60ms (66MHz, 8-bit) Hmm, that's not so bad. We're byte-banging from the CPU (through a CPLD) in SelectMap mode and it takes a couple of seconds already for an XCV2000E. Hamish -- Hamish Moffatt VK3SB ###### From: "Tim" Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... Date: Mon, 15 Oct 2001 01:26:44 +0100 Message-ID: <1003105751.25228.1.nnrp-10.9e9832fa@news.demon.co.uk> References: <3BB77CC3.DBD58021@sympatico.ca> <9p8lg2$on2$1@news-central.tiac.net> <3BC1CA87.BD87F36E@sympatico.ca> <1002936111.19967.1.nnrp-02.9e9832fa@news.demon.co.uk> <3BC911E3.1D2F5F5D@sympatico.ca> NNTP-Posting-Host: tile.demon.co.uk X-NNTP-Posting-Host: tile.demon.co.uk:158.152.50.250 X-Trace: news.demon.co.uk 1003105751 nnrp-10:25228 NO-IDENT tile.demon.co.uk:158.152.50.250 X-Complaints-To: abuse@demon.net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Lines: 66 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.tele.dk!small.news.tele.dk!212.74.64.35!colt.net!dispose.news.demon.net!news.demon.co.uk!demon!tile.demon.co.uk!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10680 "Eric" wrote > Tim wrote: > > > I disagree on the dual-use of pins. > > Could you explain why you disagree ? > What kind of problem would it create for your app ? Banking. With fast I/Os you pretty much have to take a strategic view when you allocate the I/Os, and thus the bank standards. If some of the banks (two for Virtex-II) are restricted to 3.3V, or whatever, this sure limits your options and/or complicates your work. I don't want to go overboard on this. Most of the config pins are used 'input-only', but Busy/Dout is OD/output and Init is OD. SelectMAP readback uses D0..7 bidirectionally. The official line is that VCCO should be flipped to 3.3V for all output-mode configuration pins, though probably the transistors would not tell anyone if we disobeyed, provided we made sure that the receivers were compatible. (The Virtex-II data book spells this out in more detail.) Usual form when bringing up a new board is to decide that the darned thing is _never_ going to configure. Anything to remove an engineering doubt... > Maybe all the pins that are already dual use would do better if they were > grouped on a single or a separate bank. However, I don't see where the > problem is for you since you seem to to configuration through JTAG and > you don't use these pin's alternate function. Nope. I have never tried JTAG. My usual practice is to arrange the card so that I can do an initial bring-up in slave-serial mode - cannot beat looking at the stream on DOUT :) Usually that is that, but sometimes the client wants to move to the faster SelectMap. So far, nobody has asked for JTAG config. But our work is probably not representative of civilized usage. > > Maybe the long term plan is to configure/readback the big stuff > > via JTAG only - > > It's not because you don't use other configuration methods that they're > useless. Yep, I guess I wasn't too clear. Here is the problem: Current (!) V-II parts need up to 32Mbits of config data. Click forwards a few generations and we are going North from 1Gbit. Handling this at speed cannot readily be done by extrapolating from JTAG, essentially a system designed by IBM in 1975. But it is also relatively difficult in system terms with SelectMap and its friends. I was speculating that the configuration interface will evolve to 'JTAG', if that is fast enough for you, plus 'NewTAG'. NewTAG will be a fast/smart serial link, possibly serviced at the other end by a boring old Virtex-II. Now all I need is for someone with his/her finger on the pulse to tell me that this is all being considered by IEEE Working Group 666 :) ###### From: "Andrew Brown" Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... Date: Mon, 15 Oct 2001 10:27:09 +0100 Organization: Nortel Lines: 15 Message-ID: <9qea54$2is$1@bcarh8ab.ca.nortel.com> References: <3BB77CC3.DBD58021@sympatico.ca> <9p8lg2$on2$1@news-central.tiac.net> <3BC1CA87.BD87F36E@sympatico.ca> <1002936111.19967.1.nnrp-02.9e9832fa@news.demon.co.uk> <1003014453.18501.1.nnrp-10.9e9832fa@news.demon.co.uk> NNTP-Posting-Host: pireyamd.europe.nortel.com X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!howland.erols.net!torn!qcarhaaa.nortelnetworks.com!bcarh189.ca.nortel.com!bcarh8ac.ca.nortel.com!bcarh8ab.ca.nortel.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10672 wrote in message news:B2by7.1874$bE1.12165@news1.rdc1.nsw.optushome.com.au... > Tim wrote: > > I guess. For the XC2V10000 the times work out as > > JTAG 1000ms (33MHz, 1-bit) > > Slave Serial 500ms (66MHz, 1-bit) > > SelectMap 60ms (66MHz, 8-bit) The JTAG rate of 1 sec for 10000 gates seems okay, but the devices are rated to operate at 10M. Perhaps they could improve (why is it so slow?) ###### From: "Tim" Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... Date: Mon, 15 Oct 2001 11:51:42 +0100 Message-ID: <1003147134.12948.0.nnrp-13.9e9832fa@news.demon.co.uk> References: <3BB77CC3.DBD58021@sympatico.ca> <9p8lg2$on2$1@news-central.tiac.net> <3BC1CA87.BD87F36E@sympatico.ca> <1002936111.19967.1.nnrp-02.9e9832fa@news.demon.co.uk> <1003014453.18501.1.nnrp-10.9e9832fa@news.demon.co.uk> <9qea54$2is$1@bcarh8ab.ca.nortel.com> NNTP-Posting-Host: tile.demon.co.uk X-NNTP-Posting-Host: tile.demon.co.uk:158.152.50.250 X-Trace: news.demon.co.uk 1003147134 nnrp-13:12948 NO-IDENT tile.demon.co.uk:158.152.50.250 X-Complaints-To: abuse@demon.net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Lines: 21 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeed00.sul.t-online.de!t-online.de!colt.net!dispose.news.demon.net!news.demon.co.uk!demon!tile.demon.co.uk!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10681 "Andrew Brown" wrote > > > > For the XC2V10000 the times work out as > > > JTAG 1000ms (33MHz, 1-bit) > > > Slave Serial 500ms (66MHz, 1-bit) > > > SelectMap 60ms (66MHz, 8-bit) > > > The JTAG rate of 1 sec for 10000 gates seems okay, but the devices are rated > to operate at 10M. > Perhaps they could improve (why is it so slow?) XC2V10000 is 10M (marketing) gates with 32M config bits. At 33MHz this takes approx 1 second. So slow because 33MHz is slow. But it is only a few years since 33MHz was rather fast :) ###### Message-ID: <3BCB01B0.63FEF272@sympatico.ca> From: Eric X-Mailer: Mozilla 4.6 [en] (Win98; U) X-Accept-Language: en,fr-CA,fr-FR MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... References: <3BB77CC3.DBD58021@sympatico.ca> <9p8lg2$on2$1@news-central.tiac.net> <3BC1CA87.BD87F36E@sympatico.ca> <1002936111.19967.1.nnrp-02.9e9832fa@news.demon.co.uk> <3BC911E3.1D2F5F5D@sympatico.ca> <1003105751.25228.1.nnrp-10.9e9832fa@news.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 86 Date: Mon, 15 Oct 2001 11:33:05 -0400 NNTP-Posting-Host: 64.229.194.34 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1003159901 64.229.194.34 (Mon, 15 Oct 2001 11:31:41 EDT) NNTP-Posting-Date: Mon, 15 Oct 2001 11:31:41 EDT Organization: Bell Sympatico Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.direct.ca!look.ca!news1.tor.metronet.ca!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10664 Hi, Tim wrote: > "Eric" wrote > > > Tim wrote: > > > > > I disagree on the dual-use of pins. > > > > Could you explain why you disagree ? > > What kind of problem would it create for your app ? > > Banking. With fast I/Os you pretty much have to take a strategic > view when you allocate the I/Os, and thus the bank standards. If some > of the banks (two for Virtex-II) are restricted to 3.3V, or whatever, > this sure limits your options and/or complicates your work. > If I get you well, when configuring in bit serial, the annoyance is that D0, Dout and Init_B being part of Bank 4, they force you to use 3.3V on the other IOs of that bank. Using SelectMap does the same for bank 5 (if you don't use SelectMap, bank 5 is unrestricted). A better way would be to have a specific bank that contains all dual use pins that are mandatory for all configuration modes (D0, Dout, Prog_B, Init_B, Done, M0..2, HSwap_En, TCK, TDI, TDO, TMS). As they are now, except D0 and Dout, they can't be used as IO at all. Allowing dual use and placing them in a common (voltage restricted if needed) bank would free Bank 4 in all apps, and provide up to 11 additional IOs in the same package. CS_B, RdWr_B, D1..D7 being optional, they can be put in another bank where their dual use nature would go undetected when SelectMap is not used. Same would be true for configuration address pins A0 .. An, should they be added as an option. > > > > > Maybe the long term plan is to configure/readback the big stuff > > > via JTAG only - > > > > It's not because you don't use other configuration methods that they're > > useless. > > Yep, I guess I wasn't too clear. Here is the problem: Current (!) V-II > parts need up to 32Mbits of config data. Click forwards a few generations > and we are going North from 1Gbit. Handling this at speed cannot readily > be done by extrapolating from JTAG, essentially a system designed by IBM > in 1975. But it is also relatively difficult in system terms with > SelectMap and its friends. > > I was speculating that the configuration interface will evolve to 'JTAG', > if that is fast enough for you, plus 'NewTAG'. NewTAG will be a fast/smart > serial link, possibly serviced at the other end by a boring old Virtex-II. > Sure, 33 Mhz JTAG is slow for 32 MB devices and won't cut it for future 1Gb+ FPGAs, but then a speed doubled & DDR version of SelectMap (133 Mhz x 2 ) would configure a hypothetical 1Gbit FPGA in less than 500 ms. Not that bad ! Very high speed serial could also be added whenever it will be needed, my point was that the more config modes you have, the easiest it's to integrate a FPGA in a broad range of devices and having as many dual use pins as possible reduces the number of pins that are useless (or not used by some) once the device is configured. Granted, these are not too important for high end devices that cost 4000+$ and come in FF1517 package, but at the low end (where the volume applications are) these details really make a difference. At all times, care should be taken so that whenever a mode is not used, it does not interfere with user IO usage. > > Now all I need is for someone with his/her finger on the pulse to tell me > that this is all being considered by IEEE Working Group 666 :) When there's a will, there's a way ... regards, Eric. ###### From: "Jamie Sanderson" Newsgroups: comp.arch.fpga Subject: Re: future Xilinx products wish list ... Date: Fri, 26 Oct 2001 11:13:38 -0400 Organization: Nortel Lines: 27 Message-ID: <9rbuj2$i9h$1@bcarh8ab.ca.nortel.com> References: <3BB77CC3.DBD58021@sympatico.ca> <9p8lg2$on2$1@news-central.tiac.net> <3BC1CA87.BD87F36E@sympatico.ca> <1002936111.19967.1.nnrp-02.9e9832fa@news.demon.co.uk> <1003014453.18501.1.nnrp-10.9e9832fa@news.demon.co.uk> NNTP-Posting-Host: jamie-2.ca.nortel.com X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!fr.clara.net!heighliner.fr.clara.net!feed2.onemain.com!feed1.onemain.com!feeder.qis.net!sunqbc.risq.qc.ca!torn!qcarhaaa.nortelnetworks.com!bcarh189.ca.nortel.com!bcarh8ac.ca.nortel.com!bcarh8ab.ca.nortel.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:10940 "Tim" wrote in message news:1003014453.18501.1.nnrp-10.9e9832fa@news.demon.co.uk... > wrote > > Tim wrote: > > > Maybe the long term plan is to configure/readback the big stuff > > > via JTAG only - the details of ROM handling can be farmed out to a > > > PAL. > > > > Won't that be painfully slow for large devices? > > I guess. For the XC2V10000 the times work out as > JTAG 1000ms (33MHz, 1-bit) > Slave Serial 500ms (66MHz, 1-bit) > SelectMap 60ms (66MHz, 8-bit) > > Since this is a high-speed serial world, and JTAG is usually > limited to <50MHz (33MHz on Virtex) the future is presumably > a smart JTAG extension. I haven't used JTAG for FPGA download yet, but I've heard that it takes much longer than the configuration bits divided by the JTAG clock rate due to the protocol overhead. Can anyone with experience using JTAG comment? Regards, Jamie