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
--------------4317EEBED6AC8438507EEA2C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeff, I am not going to quibble about a few percent, and yes, it will work below 25 MHz. But, how much below? The problem is that when we specify something, that allows us in the future to make changes, and to continue shipping product. Hence, if you called and said it doesn't work at 24.X MHz, the answer would be, "yes, that is true." Right now, in Virtex, Virtex E, Spartan II, and Spartan IIE, the DLL is subject to variations from process, and temperature (voltage is regulated for the delay lines). The delay lines don't use the minimum gate size just to be sure the process variations are less than they would be for the rest of the chip (and everyone thinks FPGA design is easy....bull feathers! the DLL alone has had 50+ engineer-years spent on its design alone, not even counting the verification and testing. What ASIC ever gets that much attention to one of its features?). There is sufficient safety margin over these two corners to allow for frequencies just below 25 MHz, but as I said, I would not count on there being much margin over all future time. Obviously, if we are to ship commercial grade parts, there must be a lot of headroom for the coldest temperature (0C on the die) for this to be guaranteed at 25 MHz. The industrial parts would thus have to have an even greater margin (-40C and still operate at 25 MHz). So, if you are never going to go really cold, this would be a safe bet in existing product, as presently designed and shipped (ie buy I grade, but use at > 0 C). But, if we decided to use the Virtex II temperature compensated regulator in a re-spin of the existing design for any reason (not a real possibility, but not impossible) (which removes temperature as a factor), then the margin could suddenly be less (not that we would go and make such a substantial change to an existing part! -- if it ain't broke -- don't fix it). So, the official word from the factory is "per the datasheet," but here are the things we designed to, and count on. If it were me, I would consider the product lifetime, and the temperature operating range. I would then try to keep myself warm, and keep the Vccint near nominal (don't run it high as there is some logic that runs of Vccint for the speed issue). If it is likely that the product is going to be around 5+ years then I would have to consider the risk of a "cost reduced" or "shrink" of the part appearing with its obligatory PCN notice. Then the product would need to be requalified for the application. I am sure we all take risks much greater than this in our projects, and this counts as one that is pretty tiny. As an aside, one risk NOT TO TAKE is to apply any voltage greater than the Abs Max DC voltage to the core (any Virtex, E, II or Spartan II, IIE). That is one number that we guarantee we can operate at with no damage or reliability impact for the stated life of the part. Anything greater -- and all bets are OFF. Hope this long winded treatise helps. Austin Jeff Cunningham wrote: > I have an application where I want to run a Spartan 2 DLL from a 24.576 Mhz > reference. I know the databook says 25 Mhz minimum. I recall seeing some > threads here where someone was running one on the bench at like 13 Mhz - > apparently there is a good sized guard band built into that spec. I couldn't > find any xilinx info on derating this spec based on temperature, etc. from > the xilinx web site. How risky would it be to go to production with a design > only this far over to the limit? Would someone from xilinx like to comment? > > -Jeff --------------4317EEBED6AC8438507EEA2C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Jeff, <p>I am not going to quibble about a few percent, and yes, it will work below 25 MHz. But, how much below? <p>The problem is that when we specify something, that allows us in the future to make changes, and to continue shipping product. Hence, if you called and said it doesn't work at 24.X MHz, the answer would be, "yes, that is true." <p>Right now, in Virtex, Virtex E, Spartan II, and Spartan IIE, the DLL is subject to variations from process, and temperature (voltage is regulated for the delay lines). <p>The delay lines don't use the minimum gate size just to be sure the process variations are less than they would be for the rest of the chip (and everyone thinks FPGA design is easy....bull feathers! the DLL alone has had 50+ engineer-years spent on its design alone, not even counting the verification and testing. What ASIC ever gets that much attention to one of its features?). <p>There is sufficient safety margin over these two corners to allow for frequencies just below 25 MHz, but as I said, I would not count on there being much margin over all future time. <p>Obviously, if we are to ship commercial grade parts, there must be a lot of headroom for the coldest temperature (0C on the die) for this to be guaranteed at 25 MHz. The industrial parts would thus have to have an even greater margin (-40C and still operate at 25 MHz). <p>So, if you are never going to go really cold, this would be a safe bet in existing product, as presently designed and shipped (ie buy I grade, but use at > 0 C). <p>But, if we decided to use the Virtex II temperature compensated regulator in a re-spin of the existing design for any reason (not a real possibility, but not impossible) (which removes temperature as a factor), then the margin could suddenly be less (not that we would go and make such a substantial change to an existing part! -- if it ain't broke -- don't fix it). <p>So, the official word from the factory is "per the datasheet," but here are the things we designed to, and count on. <p>If it were me, I would consider the product lifetime, and the temperature operating range. I would then try to keep myself warm, and keep the Vccint near nominal (don't run it high as there is some logic that runs of Vccint for the speed issue). If it is likely that the product is going to be around 5+ years then I would have to consider the risk of a "cost reduced" or "shrink" of the part appearing with its obligatory PCN notice. Then the product would need to be requalified for the application. <p>I am sure we all take risks much greater than this in our projects, and this counts as one that is pretty tiny. <p>As an aside, one risk <b>NOT TO TAKE</b> is to apply any voltage greater than the Abs Max DC voltage to the core (any Virtex, E, II or Spartan II, IIE). That is one number that we guarantee we can operate at with <b>no damage or reliability</b> <b>impact</b> for the stated life of the part. Anything greater -- and all bets are OFF. <p>Hope this long winded treatise helps. <p>Austin <br> <br> <p>Jeff Cunningham wrote: <blockquote TYPE=CITE>I have an application where I want to run a Spartan 2 DLL from a 24.576 Mhz <br>reference. I know the databook says 25 Mhz minimum. I recall seeing some <br>threads here where someone was running one on the bench at like 13 Mhz - <br>apparently there is a good sized guard band built into that spec. I couldn't <br>find any xilinx info on derating this spec based on temperature, etc. from <br>the xilinx web site. How risky would it be to go to production with a design <br>only this far over to the limit? Would someone from xilinx like to comment? <p>-Jeff</blockquote> </html> --------------4317EEBED6AC8438507EEA2C--Article: 37526
"David Rogoff" <drogoff@broadcom.com> schrieb im Newsbeitrag news:adwo2h5p.fsf@broadcom.com... > > I have a question about synthesis and timing reports in Xilinx ISE4.1. > I looked at the docs for the UCF file, but didn't find what I was > looking for. I want to know how to specify the load capacitance for > output pins so that synthesis and timing reports calculate the correct > prop delay through the IOB cell. Page 3-31 of the Data Book 2000 > shows how to calculate the delay manually, but I need to tell the tool > to do it. AFAIK this is not possible with the current tools. The only constraints that influenes P&R are the timingconstaints OFFSET etc. -- MfG FalkArticle: 37527
"Speedy Zero Two" <david@manorsway.freeserve.co.uk> schrieb im Newsbeitrag news:9v8ing$884$1@news6.svr.pol.co.uk... > I'll just add that > > HIGH SPEED DIGITAL DESIGN:- ISBN 0-13-395724-1 > it's a great book which explains a lot. And since we are in this business, have a look at www.signalintegrity.com Very good stuff. -- MfG FalkArticle: 37528
Dont mix well, Iam afraid. We have a small board with a XCS20XL. It is configured by a uC. Compiling it under Foundation 3.1 works fine, but compiling it using Foundation 4.1 does NOT work. DONE stays LOW, INIT stays HIGH (so no CRC error) Even very simple tests (route through and toggle-FF) dont work. I checked all Foundation settings, they should be the same. I checked the Xilinx website, nothing. :-(( Any hints? -- MfG FalkArticle: 37529
On Thu, 13 Dec 2001 18:23:08 +0100, "Falk Brunner" <Falk.Brunner@gmx.de> wrote: >Dont mix well, Iam afraid. We have a small board with a XCS20XL. It is >configured by a uC. Compiling it under Foundation 3.1 works fine, but >compiling it using Foundation 4.1 does NOT work. DONE stays LOW, INIT stays >HIGH (so no CRC error) >Even very simple tests (route through and toggle-FF) dont work. >I checked all Foundation settings, they should be the same. >I checked the Xilinx website, nothing. :-(( > >Any hints? Create the bitstreams in .RBT format and look at them. Although the guts of the bit streams will be different, the lengths should be identical, as should the header bits, and the bits right at the end. Your problem sounds very much like the "I need to clock a few more ones in at the end of the bitstream" Philip Philip Freidin FliptronicsArticle: 37530
I published a 2-pager in 1994 ( ages ago, but the concepts still hold ) in the 1994 Xilinx Data Book, pages 2-1 and 2-4. "A Technical Overview for the First-Time User". I do not have this in electronic form, but could fax it to you, if you want me to. Peter Alfke ====================================== Jason Langkamer-Smith wrote: > Hello, > > Can someone direct me to a good introduction to FPGAs? <snip> > I am a science journalist > preparing an article about FPGAs for the general public. > > Thank you, > > Jason Langkamer-Smith > jasonls@msn.comArticle: 37531
"Guy-Armand" <gkamendje@iaik.at> writes: > Unfortunately the command line tools are not accessible in webpack 4.1 (I am > using 4.1 and not 4.2 as I wrote early). Is it possible for you to use jtagprog from the webpack 3 release? Make a small bat file setting the XILINX variable and use the full path to start jtagprog? Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 37532
This article can be found at http://www.xilinx.com/xapp/xapp097.pdf Peter Alfke wrote: > I published a 2-pager in 1994 ( ages ago, but the concepts still hold ) in the > 1994 Xilinx Data Book, pages 2-1 and 2-4. "A Technical Overview for the > First-Time User". > I do not have this in electronic form, but could fax it to you, if you want me > to. > > Peter Alfke > ====================================== > Jason Langkamer-Smith wrote: > > > Hello, > > > > Can someone direct me to a good introduction to FPGAs? <snip> > > > I am a science journalist > > preparing an article about FPGAs for the general public. > > > > Thank you, > > > > Jason Langkamer-Smith > > jasonls@msn.com -- Marc Baker Xilinx ApplicationsArticle: 37533
Guy I noticed this with Virtex-E, Both SVF files should be valid but the newer version is smaller. Basically the Jtag state machine is being used more efficiently. I have different issues with the data that iMPACK provides given this new file, If you use Xilinx software you should be OK but I'm using my embedded software and it looks like there is a couple of discrepency somewhere. Are you using your own software to program your device ? Dave "Guy-Armand" <gkamendje@iaik.at> wrote in message news:9v9neb$71i$1@fstgss02.tu-graz.ac.at... > Hi, > When using webpack 3, I was able to create .svf files for CPLD devices. But > now when selecting the "Generate Programming File" and entering the IMPACT > window, I can choose between Boundary Scan, Slave Serial and Select Map. I > have all these options but all the same the .svf file that is created is not > the same as the one created by previous version of Webpack. The current file > is only 553kb instead of 867kb. (I have no cable connected to my computer). > Please could someone help me choosing the right options for creating a .svf > file for xc9500 device programming? I am using a parrallel cable to download > the .svf files to the board. > Thanks for any hint. > Guy > >Article: 37534
--------------F67BA72F385B684BEF04C090 Content-Type: text/plain; charset=iso-8859-1; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 8bit Peter Alfke wrote: > I published a 2-pager in 1994 ( ages ago, but the concepts still hold ) in the > 1994 Xilinx Data Book, pages 2-1 and 2-4. "A Technical Overview for the > First-Time User". Since Jason's e-mail does not accept traffic, I have to put it on the newsgroup. Please ignore this old stuff unless you are a history buff. Obviously, I will have to revamp this before it gets used seriously... Peter A Technical Overview for the First-Time User In the XC3000, XC4000, and XC5200 device families, Xilinx offers three evolutionary and compatible generations of Field Programmable Gate Arrays (FPGAs). Here is a short description of their common features. Every Xilinx FPGA performs the function of a custom LSI circuit, such as a gate array, but the FPGA is user-programmable and even reprogrammable in the system. Xilinx sells standard off-the-shelf devices in three families, and many different sizes, speeds, operating-temperature ranges, and packages. The user selects the appropriate Xilinx FPGA, and then converts the schematic or High-Level-Language description into a configuration data file, using the Xilinx development system software running on a PC or workstation, and then loads this file into the Xilinx FPGA. This overview describes two different aspects of Xilinx FPGAs, what kind of logic resources are available for the user, and how the devices are programmed. User Logic General Structure Different in structure from traditional logic circuits, or PALs, EPLDs and even gate arrays, the Xilinx FPGAs implement combinatorial logic in small look-up tables (16 x 1 ROMs); each such table either feeds the D-input of a flip-flop or drives other logic or I/O. Each FPGA contains a matrix of identical logic blocks, usually square, from 8 x 8 in the XC3020 to 68 x 68 in the XC40125XV. Metal lines of various lengths run horizontally and vertically in-between these logic blocks, selectively interconnecting them or connecting them to the input/output blocks. Logic Blocks This modular architecture is rich in registers and powerful function generators that can implement any function of up to five variables. For wider inputs, function generators are easily concatenated. Generous on-chip buffering makes logic block delays insensitive to loading by the interconnect structure, but interconnect delays are layout-dependent and must be analyzed if they are performance-critical. Clocks Clock lines are well-buffered and can drive all flip-flops with < 2 ns skew from chip corner to corner, even throughout the biggest device. The user need not worry about clock loading or clock-delay balancing, or about hold-time issues on the chip, if the designated global clock lines are used. There are eight such global low-skew clock lines in XC4000, four in XC5200, and two in XC3000 devices. Special Features All devices can implement internal bidirectional busses. The XC4000- and XC5200-family devices have dedicated fast carry circuits that improve the efficiency and speed of adders, subtractors, comparators, accumulators and synchronous counters. These families also supports boundary scan on every pin. Outputs All device pins are available as bidirectional user l/O, with the exception of the supply connections and three pins dedicated to the configuration process. All inputs and outputs within each family have identical electrical characteristics, but output current capability varies among families: The XC3000 outputs are specified to sink 4 mA; XC3100 and XC5200, 8 mA; XC4000, 12 mA. The outputs on XC3000/XC3100 and XC5200 devices always swing rail-to-rail, while XC4000 outputs are n-channel-only, "totem-pole", with lower VOH for higher speed. XC4000E/EX outputs have a global configuration choice between ìTTL = totem poleî or ìCMOS = rail-to-railî output swing. The original families operate from a 5-V supply voltage, but all three have added 3.3-V variants. These 3.3-V devices, designated by an ìLî in their product name, have rail-to-rail outputs. Inputs Inputs of all 5-V devices can be globally configured for either TTL-like input thresholds or mid-rail CMOS thresholds. All 3.3-V devices have CMOS input thresholds (50% of Vcc). All inputs have hysteresis (Schmitt-trigger action) of 100 to 200 mV. XC4000XL and XC4000XV inputs are unconditionally 5-V tolerant, even while their supply voltage is as low as 0 V. This eliminates all power-supply sequencing problems. Global Reset All Xilinx FPGAs have a global asynchronous reset input affecting all device flip-flops. In the XC4000- and XC5200-family devices, any pin can be configured as a reset input; in XC3000-families, RESET is a dedicated pin. Power Consumption Since all Xilinx FPGAs use CMOS-SRAM technology, their quiescent or stand-by power consumption is very low, a few microwatts for XC3000 devices, max 25 mW for XC3100, max 50 mW for XC4000 and max 75 mW for XC5200 devices. The operational power consumption is totally dynamic, proportional to the transition frequency of inputs, outputs, and internal nodes. Typical power consumption is between 100 mW and 5 W, depending on device size, clock rate, and the internal logic structure. XC3000-family devices can be powered-down, and in this state their configuration can be maintained by a >2.3 V battery. Current consumption is only a few microamps. The device 3-states all outputs, ignores all inputs, and resets its flip-flops, but retains its configuration. All devices monitor Vcc continuously and shut down when they detect a Vcc drop to 3 V (2 V for 3.3-V devices). The device then 3-states all outputs and prepares for reconfiguration. Programming or Configuring the Device Design Entry A design usually starts as a schematic, drawn with one of the popular CAE tools, or as a High-Level Language textual description. Most popular CAE tools have an interface to the Xilinx development system, running on PCs or popular workstations. Design Implementation After schematic- or HLL design entry, the logic is automatically converted to a Xilinx Netlist Format (XNF) or EDIF. The Xilinx software first partitions the design into logic blocks, then finds a near-optimal placement for each block, and finally selects the interconnect routing. This process of partitioning the logic, placing it on the chip, and routing the interconnects runs automatically, but the user may also affect the outcome by imposing specific timing constraints, or selectively editing critical portions of the design, using the graphic design editor. The user thus has a wide range of choices between a fully automatic implementation and detailed involvement in the layout process. Once the design is complete, a detailed timing report is generated and a serial bitstream can be downloaded into the FPGA, into a PROM programmer, or made available as a computer file. Configuring the FPGA The user then exercises one of several options to load this file into the Xilinx FPGA device, where it is stored in latches, arranged to resemble one long shift register. The data content of these latches customizes the FPGA to perform the intended digital function. The number of configuration bits varies with device type, from 14,819 bits for the smallest device (XC3020) to over 3 million bits for the largest device presently available (XC40125XV). Multiple FPGA devices can be daisy-chained and configured with one concatenated bitstream. Device utilization does not change the number of configuration bits. Inside the device, these configuration bits control or define the combinatorial circuitry, flip-flops, interconnect structure, and the I/O buffers, as well as their pull-up or pull-down resistors, input threshold and output slew rate Power-up Sequence Upon power-up, the device waits for Vcc to reach an acceptable level, then clears the configuration memory, holds all internal flip-flops reset, and 3-states the outputs but activates their weak pull-up resistors. The device then initiates configuration, either as a master, (clocking a serial PROM to receive the serial bitstream or addressing a byte-parallel EPROM), or as a slave, (accepting a clock and bit-serial or 8-bit parallel data from an external source). Bit-Serial Configuration The Xilinx serial PROM is the simplest way to configure the FPGA, using only three or four device pins. Typical configuration time is around one microsecond per bit, but this can be reduced by a factor of eight. Configuration thus takes from a few milliseconds to a several hundred milliseconds. Xilinx serial PROMs come in sizes from 18,144 to 262,144 bits, and megabit versions are in development. Serial PROMs can also be daisy-chained to store a longer bitstream. Byte-Parallel Configuration Xilinx FPGA devices can also be configured with byte-wide data, either from an industry-standard PROM or from a microprocessor. The FPGA drives the PROM addresses directly, or it handshakes with the microprocessor like a typical peripheral. The byte-wide data is immediately converted into an internal serial bitstream, clocked by the internal Configuration Clock (CCLK). Parallel configuration modes are, therefore, not faster than serial modes. XC5200 devices, however, can also be configured in Express mode, with byte-wide data at 10 MHz. The largest device, XC5215, can thus be configured in only 3 ms. Reconfiguration The user can reconfigure the device at any time by pulling the PROGRAM pin Low, to initiate a new configuration sequence. During this process, all outputs not used for configuration are 3-stated. Partial reconfiguration is not possible. Readback of Configuration Data After the device has been programmed, the content of the configuration "shift register" can be read back serially, without interfering with device operation. XC4000- and XC5200-family devices include a synchronized simultaneous transfer of all user-register information into the configuration registers. This adds in-circuit-emulation capability to the readback function. Quality and Reliability Since 1985, Xilinx has shipped over 70 million FPGA devices. Industry-leading quality and reliability (ESD protection, AQL and FIT) and aggressive price reductions have undoubtably contributed to this success. Peter Alfke, August 20, 1997 YES: 1997, late middle ages :-) --------------F67BA72F385B684BEF04C090 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <p>Peter Alfke wrote: <blockquote TYPE=CITE>I published a 2-pager in 1994 ( ages ago, but the concepts still hold ) in the <br>1994 Xilinx Data Book, pages 2-1 and 2-4. "A Technical Overview for the <br>First-Time User".</blockquote> Since Jason's e-mail does not accept traffic, I have to put it on the newsgroup. Please ignore this old stuff unless you are a history buff. <br>Obviously, I will have to revamp this before it gets used seriously... <br>Peter <p> <h3> A Technical Overview for the First-Time User</h3> <p><br> In the XC3000, XC4000, and XC5200 device families, Xilinx offers three <br> evolutionary and <br> compatible generations of Field Programmable Gate Arrays (FPGAs). <br> Here is a short description of their common features. <p> Every Xilinx FPGA performs the function of a custom LSI circuit, such as <br> a gate array, but the FPGA is user-programmable and even <br> reprogrammable in the system. Xilinx sells standard off-the-shelf <br> devices in three families, and many different sizes, speeds, <br> operating-temperature ranges, and packages. The user selects the <br> appropriate Xilinx FPGA, and then converts the schematic or <br> High-Level-Language description into a configuration data file, using <br> the Xilinx development system software running on a PC or workstation, <br> and then loads this file into the Xilinx FPGA. <p> This overview describes two different aspects of Xilinx FPGAs, <p> what kind of logic resources are available for the user, and <br> how the devices are programmed. <p> <h3> User Logic</h3> <p><br> General Structure <br> Different in structure from traditional logic circuits, or PALs, EPLDs <br> and even gate arrays, the Xilinx FPGAs implement combinatorial logic <br> in small look-up tables (16 x 1 ROMs); each such table either feeds the <br> D-input of a flip-flop or drives other logic or I/O. Each FPGA contains a <br> matrix of identical logic blocks, usually square, from 8 x 8 in the XC3020 <br> to 68 x 68 in the XC40125XV. Metal lines of various lengths run <br> horizontally and vertically in-between these logic blocks, selectively <br> interconnecting them or connecting them to the input/output blocks. <p> Logic Blocks <br> This modular architecture is rich in registers and powerful function <br> generators that can implement any function of up to five variables. For <br> wider inputs, function generators are easily concatenated. Generous <br> on-chip buffering makes logic block delays insensitive to loading by the <br> interconnect structure, but interconnect delays are layout-dependent <br> and must be analyzed if they are performance-critical. <p> Clocks <br> Clock lines are well-buffered and can drive all flip-flops with < 2 ns skew <br> from chip corner to corner, even throughout the biggest device. The <br> user need not worry about clock loading or clock-delay balancing, or <br> about hold-time issues on the chip, if the designated global clock lines <br> are used. There are eight such global low-skew clock lines in XC4000, <br> four in XC5200, and two in XC3000 devices. <p> Special Features <br> All devices can implement internal bidirectional busses. The XC4000- <br> and XC5200-family devices have dedicated fast carry circuits that <br> improve the efficiency and speed of adders, subtractors, comparators, <br> accumulators and synchronous counters. These families also supports <br> boundary scan on every pin. <p> Outputs <br> All device pins are available as bidirectional user l/O, with the <br> exception of the supply connections and three pins dedicated to the <br> configuration process. All inputs and outputs within each family have <br> identical electrical characteristics, but output current capability varies <br> among families: The XC3000 outputs are specified to sink 4 mA; XC3100 <br> and XC5200, 8 mA; XC4000, 12 mA. The outputs on XC3000/XC3100 and <br> XC5200 devices always swing rail-to-rail, while XC4000 outputs are <br> n-channel-only, "totem-pole", with lower VOH for higher speed. <br> XC4000E/EX outputs have a global configuration choice between “TTL <br> = totem pole” or “CMOS = rail-to-rail” output swing. <p> The original families operate from a 5-V supply voltage, but all three <br> have added 3.3-V variants. These 3.3-V devices, designated by an “L” in <br> their product name, have rail-to-rail outputs. <p> Inputs <br> Inputs of all 5-V devices can be globally configured for either TTL-like <br> input thresholds or mid-rail CMOS thresholds. All 3.3-V devices have <br> CMOS input thresholds (50% of Vcc). All inputs have hysteresis <br> (Schmitt-trigger action) of 100 to 200 mV. XC4000XL and XC4000XV <br> inputs are unconditionally 5-V tolerant, even while their supply voltage <br> is as low as 0 V. This eliminates all power-supply sequencing problems. <p> Global Reset <br> All Xilinx FPGAs have a global asynchronous reset input affecting all <br> device flip-flops. In the XC4000- and XC5200-family devices, any pin <br> can be configured as a reset input; in XC3000-families, RESET is a <br> dedicated pin. <p> Power Consumption <br> Since all Xilinx FPGAs use CMOS-SRAM technology, their quiescent or <br> stand-by power consumption is very low, a few microwatts for XC3000 <br> devices, max 25 mW for XC3100, max 50 mW for XC4000 and max 75 <br> mW for XC5200 devices. The operational power consumption is totally <br> dynamic, proportional to the transition frequency of inputs, outputs, <br> and internal nodes. Typical power consumption is between 100 mW <br> and 5 W, depending on device size, clock rate, and the internal logic <br> structure. <p> XC3000-family devices can be powered-down, and in this state their <br> configuration can be maintained by a >2.3 V battery. Current <br> consumption is only a few microamps. The device 3-states all outputs, <br> ignores all inputs, and resets its flip-flops, but retains its configuration. <p> All devices monitor Vcc continuously and shut down when they detect a <br> Vcc drop to 3 V (2 V for 3.3-V devices). The device then 3-states all <br> outputs and prepares for reconfiguration. <p> <h3> Programming or Configuring the Device</h3> <p><br> Design Entry <br> A design usually starts as a schematic, drawn with one of the popular <br> CAE tools, or as a High-Level Language textual description. Most <br> popular CAE tools have an interface to the Xilinx development system, <br> running on PCs or popular workstations. <p> Design Implementation <br> After schematic- or HLL design entry, the logic is automatically <br> converted to a Xilinx Netlist Format (XNF) or EDIF. The Xilinx software <br> first partitions the design into logic blocks, then finds a near-optimal <br> placement for each block, and finally selects the interconnect routing. <br> This process of partitioning the logic, placing it on the chip, and routing <br> the interconnects runs automatically, but the user may also affect the <br> outcome by imposing specific timing constraints, or selectively editing <br> critical portions of the design, using the graphic design editor. The user <br> thus has a wide range of choices between a fully automatic <br> implementation and detailed involvement in the layout process. <p> Once the design is complete, a detailed timing report is generated and <br> a serial bitstream can be downloaded into the FPGA, into a PROM <br> programmer, or made available as a computer file. <p> Configuring the FPGA <br> The user then exercises one of several options to load this file into the <br> Xilinx FPGA device, where it is stored in latches, arranged to resemble <br> one long shift register. The data content of these latches customizes the <br> FPGA to perform the intended digital function. The number of <br> configuration bits varies with device type, from 14,819 bits for the <br> smallest device (XC3020) to over 3 million bits for the largest device <br> presently available (XC40125XV). Multiple FPGA devices can be <br> daisy-chained and configured with one concatenated bitstream. <br> Device utilization does not change the number of configuration bits. <br> Inside the device, these configuration bits control or define the <br> combinatorial circuitry, flip-flops, interconnect structure, and the I/O <br> buffers, as well as their pull-up or pull-down resistors, input threshold <br> and output slew rate <p> Power-up Sequence <br> Upon power-up, the device waits for Vcc to reach an acceptable level, <br> then clears the configuration memory, holds all internal flip-flops reset, <br> and 3-states the outputs but activates their weak pull-up resistors. The <br> device then initiates configuration, either as a master, (clocking a serial <br> PROM to receive the serial bitstream or addressing a byte-parallel <br> EPROM), or as a slave, (accepting a clock and bit-serial or 8-bit parallel <br> data from an external source). <p> Bit-Serial Configuration <br> The Xilinx serial PROM is the simplest way to configure the FPGA, <br> using only three or four device pins. Typical configuration time is <br> around one microsecond per bit, but this can be reduced by a factor of <br> eight. Configuration thus takes from a few milliseconds to a several <br> hundred milliseconds. Xilinx serial PROMs come in sizes from 18,144 to <br> 262,144 bits, and megabit versions are in development. Serial PROMs <br> can also be daisy-chained to store a longer bitstream. <p> Byte-Parallel Configuration <br> Xilinx FPGA devices can also be configured with byte-wide data, either <br> from an industry-standard PROM or from a microprocessor. The FPGA <br> drives the PROM addresses directly, or it handshakes with the <br> microprocessor like a typical peripheral. The byte-wide data is <br> immediately converted into an internal serial bitstream, clocked by the <br> internal Configuration Clock (CCLK). Parallel configuration modes are, <br> therefore, not faster than serial modes. XC5200 devices, however, can <br> also be configured in Express mode, with byte-wide data at 10 MHz. <br> The largest device, XC5215, can thus be configured in only 3 ms. <p> Reconfiguration <br> The user can reconfigure the device at any time by pulling the <br> PROGRAM pin Low, to initiate a new configuration sequence. During <br> this process, all outputs not used for configuration are 3-stated. Partial <br> reconfiguration is not possible. <p> Readback of Configuration Data <br> After the device has been programmed, the content of the <br> configuration "shift register" can be read back serially, without <br> interfering with device operation. XC4000- and XC5200-family devices <br> include a synchronized simultaneous transfer of all user-register <br> information into the configuration registers. This adds <br> in-circuit-emulation capability to the readback function. <p> Quality and Reliability <br> Since 1985, Xilinx has shipped over 70 million FPGA devices. <br> Industry-leading quality and reliability (ESD protection, AQL and FIT) <br> and aggressive price reductions have undoubtably contributed to this <br> success. <br> <br> Peter Alfke, August 20, <b>1997 YES: 1997, late middle ages :-)</b> <br> </html> --------------F67BA72F385B684BEF04C090--Article: 37535
FYI: The command line of iMPACT is invoked by typing "impact -batch" in a command prompt window. Guy-Armand wrote: > "Petter Gustad" <newsmailcomp1@gustad.com> wrote in message > news:m3bsh3bcmp.fsf@scimul.dolphinics.no... > > "Guy-Armand" <gkamendje@iaik.at> writes: > > > > > Hi, > > > When using webpack 3, I was able to create .svf files for CPLD devices. > But > > > now when selecting the "Generate Programming File" and entering the > IMPACT > > > window, I can choose between Boundary Scan, Slave Serial and Select Map. > I > > > have all these options but all the same the .svf file that is created is > not > > > the same as the one created by previous version of Webpack. The current > file > > > is only 553kb instead of 867kb. (I have no cable connected to my > computer). > > > Please could someone help me choosing the right options for creating a > .svf > > > file for xc9500 device programming? I am using a parrallel cable to > download > > > the .svf files to the board. > > > Thanks for any hint. > > > > Are the command line tools accessible in webpack 3? If so try to use > > the command line tools. > > > > jtagprog -svf -batch yourfile.cmd > > > > And yourfile.cmd contains something like this (top level design name > > is pld, there is only one part in the scan chain): > > > > part XC95144XL:pld > > program -v pld > > quit > Unfortunately the command line tools are not accessible in webpack 4.1 (I am > using 4.1 and not 4.2 as I wrote early). > GuyArticle: 37536
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> iMPACT SVF files are smaller than those generated by JTAGProgrammer because iMPACT <br>makes use of several SVF language constructs that reduce the overall SVF file size, as follows: <ol> <li> HIR, HDR, TIR, TDR commands are used to delineate static shift data related to devices surrounding the target device.</li> <li> The MASK and SMASK are not reproduced with each SDR making use of the SVF rule that previously specified MASK and SMASK apply when these values are unspecified.</li> </ol> For more information on SVF please visit: <a href="http://www.asset-intertech.com/support/svf.html#access">http://www.asset-intertech.com/support/svf.html#access</a> <br> <p>Guy-Armand wrote: <blockquote TYPE=CITE>Hi, <br>When using webpack 3, I was able to create .svf files for CPLD devices. But <br>now when selecting the "Generate Programming File" and entering the IMPACT <br>window, I can choose between Boundary Scan, Slave Serial and Select Map. I <br>have all these options but all the same the .svf file that is created is not <br>the same as the one created by previous version of Webpack. The current file <br>is only 553kb instead of 867kb. (I have no cable connected to my computer). <br>Please could someone help me choosing the right options for creating a .svf <br>file for xc9500 device programming? I am using a parrallel cable to download <br>the .svf files to the board. <br>Thanks for any hint. <br>Guy</blockquote> </html>Article: 37537
Intel Xeon. Up to 2M (4M?) cache parts are available. Gary. "Tim" <tim@rockylogic.com.nooospam.com> wrote in message news:<1008035495.10050.0.nnrp-10.9e9832fa@news.demon.co.uk>... > Guessing that cache size has a first order effect on > sim/compilation timing (!), are there any 'commodity' PCs > which have better-than-average secondary/tertiary caches? > > Or are all the cache arrangements dictated by the chipset > manufacturers, and effectively identical? > > As I recall, Athlon primary cache size = 2x Duron, and > similarly for P[3|4]/Celeron.Article: 37538
I have a state machine implemented in a 22V10 with PALASM.It works fine, the problem is I am trying to implement a command to reset the state machine to its idle state (all flip-flops at 1) in case it ever goes into the weeds. To do this I use the synchronous preset available in the 22V10. Here is the problem, it will not reset to the idle state. Here is a portion of my code: Chip machine PAL22V10 NODE 1 GLOBAL COMB later GLOBAL.SETF=GOODCMD*/CTRL3*/CTRL2*/CTRL1*/CTRL0 where CTRLn is an input pin in the simulation I try: preload ILLEGAL4 setf /CTRL3 /CTRL2 /CTRL1 /CTRL0 clockf CLOCK check IDLE I get errors on check IDLE. Even in the simulation, the state machine is not being reset to all 1s. The design works fine, except for this part (the reset command). This neither works on the bench nor in the simulation. I think I am doing everything right according to the PALASM manual. What could be going on. I have checked Google newsgroups and have found nothing which could help. Thank youArticle: 37539
hi, I want to know the relation ship between the net delay and Period. I have implemented a design in xilinx Virtex chip, the post layout timing report said --------------------------------------------------------------------------- Timing errors: 0 Score: 0 Constraints cover 6493041 paths, 4449 nets, and 12818 connections (100.0% coverage) Design statistics: Minimum period: 54.350ns (Maximum frequency: 18.399MHz) Maximum net delay: 21.751ns Analysis completed Wed Dec 12 01:20:58 2001 -------------------------------------------------------------------------------- I redesigned the design to reduce the net delay, When i implemented it the net delay was reduced, but period has increased. The second result was --------------------------------------------------------------------------- Timing summary: --------------- Timing errors: 0 Score: 0 Constraints cover 6494915 paths, 4879 nets, and 13544 connections (100.0% coverage) Design statistics: Minimum period: 58.314ns (Maximum frequency: 17.149MHz) Maximum net delay: 18.163ns Analysis completed Fri Dec 14 10:27:21 2001 --------------------------------------------------------------------------- Could some one tell what is the relation ship between the period and net delay, Does the target frequency, that we set, has any effect on the design, i have set that one to a low value(10Mhz) Also, How to analyse the worst net delay, it is given in some format, how to interpret it. Is the information given above enough, Do i miss something Thanks a lot. RamnathArticle: 37540
I'm preparing a QPSK modulator, until now I arrange it for a VIRTEX 1000 -4 , but it seem that could be impossible to use it at a maximum clock speed of 165MHz especially 'cause I've to put in and out that speed and this seems not possible (..or I'm wrong ??) I'm using less than 30% of VIRTEX 1000 so my question is which FPGA is actually the one with best speed performance, it could be not only Xilinx 'cause my scope is to verify that there's actually a technology where my project could be implemented. Thanks AntonioArticle: 37541
In article <3C18CEA8.AD5C292A@egr.msu.edu>, Theron Hicks <hicksthe@egr.msu.edu> writes >Actually you are right if one is using software older than ise4.1. 4.1 has >greatly reduced the hassle. now you need the library declaration > >-- synopsys translate_off > >Library XilinxCoreLib; > >-- synopsys translate_on > >and then declare the component and instantiate as normal. when you create the >core a .xoc file will be added to your project and a .vho file will show the >appropriate declaration and instantiation code. just cut and paste the >appropriate stuff. It is much easier that the old approach. > >Theron Hicks > Thanks for the tip Theron. We haven't upgraded to 4.1 yet as we still use the Xchecker cable for some simple demos on our courses. Also, after replying, I got an email from the original poster, and he is using Verilog anyway - Doh! regards Alan <snip> -- Alan Fitch DOULOS Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom Tel: +44 1425 471223 Email: alan.fitch@doulos.com Fax: +44 1425 471573 Web: http://www.doulos.com ********************************** ** Developing design know-how ** ********************************** This e-mail and any attachments are confidential and Doulos Ltd. reserves all rights of privilege in respect thereof. It is intended for the use of the addressee only. If you are not the intended recipient please delete it from your system, any use, disclosure, or copying of this document is unauthorised. The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 37542
Hi all, I need a ram that has an input (write) data port, output (read) data port, write-address port, and read-address port. I need to write to a different part of ram that is currently being read. Are there any cheap/free tools that recognize a vhdl template for this function? I'm using an Acex 1k30 device.Article: 37543
Hi folks, I was wondering if anyone knew if there is a random number generator facility in Handel-C. I'm using version 3.0. Any help would be much appreciated, Cheers and THX, Rob.Article: 37544
You could try taking a look at Expressive-III from Expressive Systems (www.expressivesystems.com). It's not exactly a schematic editor but you may find it useful for documenting your design. --- Duncan "AAP3" <aams@dr.com> wrote in message news:my%R7.26654$OD3.3314278@typhoon.columbus.rr.com... > Can someone pleas point me to inexpensive datapath schematic editor. > I have ton of datapath schematics I have to draw for a report. > > Thanks.Article: 37545
You describe the need for a dual-ported RAM. Any dual-ported RAM should do your job, even the ones that are not "true dual-ported RAMs", i.e. the ones that have one read port and one write port. I do not know about ACEX, but all Xilinx BlockRAMs have always been fully symmetrical, i.e. true dual port RAMs where either port can read or write, independent of the other.. Peter Alfke ============================== Russell Shaw wrote: > Hi all, > > I need a ram that has an input (write) data port, output (read) > data port, write-address port, and read-address port. I need to > write to a different part of ram that is currently being read. > Are there any cheap/free tools that recognize a vhdl template > for this function? I'm using an Acex 1k30 device.Article: 37546
I am having a similar problem. Are the webpack 3 tools still available t= o=20 download.=20 I have since upgraded everything to 4.1 and don't have the old tools=20= around. Tom >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 12/13/2001, 5:09:02 AM, Petter Gustad <newsmailcomp1@gustad.com> wrot= e=20 regarding Re: svf files in webpack 4.2: > "Guy-Armand" <gkamendje@iaik.at> writes: > > Hi, > > When using webpack 3, I was able to create .svf files for CPLD devic= es.=20 But > > now when selecting the "Generate Programming File" and entering the = IMPACT > > window, I can choose between Boundary Scan, Slave Serial and Select = Map.=20 I > > have all these options but all the same the .svf file that is create= d is=20 not > > the same as the one created by previous version of Webpack. The curr= ent=20 file > > is only 553kb instead of 867kb. (I have no cable connected to my=20= computer). > > Please could someone help me choosing the right options for creating= a=20 .svf > > file for xc9500 device programming? I am using a parrallel cable to = download > > the .svf files to the board. > > Thanks for any hint. > Are the command line tools accessible in webpack 3? If so try to use > the command line tools. > jtagprog -svf -batch yourfile.cmd > And yourfile.cmd contains something like this (top level design name > is pld, there is only one part in the scan chain): > part XC95144XL:pld > program -v pld > quit > Petter > -- > ______________________________________________________________________= __ > Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.c= omArticle: 37547
I think he was looking for a low cost or free tool that would infer one. If your tools do not support RAM inference, then you can always instantiate the RAM primitive. I usually just instantiate the primitive because it gives me more portability between tools and more flexibility in describing what I want (and you don't have to rely on the tool for doing the right thing, especially in regards to a dual ported memory). Peter Alfke wrote: > You describe the need for a dual-ported RAM. Any dual-ported RAM > should do your job, even the ones that are not "true dual-ported > RAMs", i.e. the ones that have one read port and one write port. I > do not know about ACEX, but all Xilinx BlockRAMs have always been > fully symmetrical, i.e. true dual port RAMs where either port can > read or write, independent of the other.. > > Peter Alfke > ============================== > Russell Shaw wrote: > > > Hi all, > > > > I need a ram that has an input (write) data port, output (read) > > data port, write-address port, and read-address port. I need to > > write to a different part of ram that is currently being read. > > Are there any cheap/free tools that recognize a vhdl template > > for this function? I'm using an Acex 1k30 device. -- --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: 37548
"Philip Freidin" <philip@fliptronics.com> schrieb im Newsbeitrag news:0e0i1ugsb6ouidtrtc7an47use51ltifpb@4ax.com... > On Thu, 13 Dec 2001 18:23:08 +0100, "Falk Brunner" <Falk.Brunner@gmx.de> wrote: > >Dont mix well, Iam afraid. We have a small board with a XCS20XL. It is > >configured by a uC. Compiling it under Foundation 3.1 works fine, but > >compiling it using Foundation 4.1 does NOT work. DONE stays LOW, INIT stays > >HIGH (so no CRC error) > >Even very simple tests (route through and toggle-FF) dont work. > >I checked all Foundation settings, they should be the same. > >I checked the Xilinx website, nothing. :-(( > > > >Any hints? > > Create the bitstreams in .RBT format and look at them. Although the guts of We use the MCS format, this is then converted into a C sourcefile. The MCS files from Foundatiopn 3.1/4.1 have exactly the same lenght. The first few hundred bytes are the same, and so are the last lines of bytes. > the bit streams will be different, the lengths should be identical, as > should the header bits, and the bits right at the end. > > Your problem sounds very much like the "I need to clock a few more ones in > at the end of the bitstream" Hmm??? I dont think so. I hooked up a frequency counter onto CCLK, with the working image, ther are somethig like 179xxx clocks, with the non working image there are around 20 cycles more, which is the normal behaviour of the loader routine. -- MfG Falk > > Philip > > Philip Freidin > FliptronicsArticle: 37549
Thanks Duncan. "Duncan Crowther" <duncanc@euro-eda.com> wrote in message news:1008338705.12117.0.nnrp-14.d4e46173@news.demon.co.uk... > You could try taking a look at Expressive-III from Expressive Systems > (www.expressivesystems.com). It's not exactly a schematic editor but you may > find it useful for documenting your design. > --- > Duncan > > > "AAP3" <aams@dr.com> wrote in message > news:my%R7.26654$OD3.3314278@typhoon.columbus.rr.com... > > Can someone pleas point me to inexpensive datapath schematic editor. > > I have ton of datapath schematics I have to draw for a report. > > > > Thanks. > >
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