Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hi Hamish, hamish@cloud.net.au wrote: > > Kenneth <kenneth.lee@terapower.com.hk> wrote: > > Within the design, it is supposed the the timing constraint for > > the logic using the clk_4x should be 5ns. However, from the > > timing report it showed a strange result. It shows that the > > requirement is 2.5ns rather than the 5ns, and the timing of > > the rising edge of the clk_4x signal is very strange too. > > > Do anyone have idea about this problem? Thanks in advance. > > Could you post your UCF and possibly also your code? In UCF, I set the timing constraint for the 50MHz input clock (bclk_in) which is NET "bclk_in" TNM_NET = "bclk_in"; TIMESPEC "TS_bclk_in" = PERIOD "bclk_in" 20 ns HIGH 50 %; But I feel stange that why for the clock signal clk_4x, the timing report shows that Source Clock: clk_4x rising at 7.500ns Destination Clock: clk_4x rising at 10.000ns while it should be 5ns between 2 rising edges. > By the way you might encounter a lot of clock jitter with > this arrangement. Especially with two DCMs in series. The > best approach would be to have a 200MHz clock input pin > and to create 50 and 100MHz clocks from that. If you have > Virtex-II you could use the CLKFX (synthesized output) > and the CLK2X on a single DCM instead of two in series. Actaully I am using Virtex-II 1000 decive. However, due to the limitions of the Engineering Sample(I am using it....), it is not recommanded to use the CLKFX to produce the 4X clock from the 50MHz clock input directly. As a result, I need to use 2 DCMs to achieve the 4X clock signal. > regards > Hamish > -- > Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au> Thanks. Regards, KennethArticle: 38076
A few months ago, there was a guy who claimed that he figured out how to
synthesize (technically synthesizing is not the correct word, processing
a netlist should be correct) Xilinx's PCI LogiCORE with XST.
To retrieve the past posting I am talking about, try doing a Google
Groups search (http://groups.google.com/groups?group=comp.arch.fpga) for
comp.arch.fpga "only" with the following titles.
Xilinx PCI core and XST
Xilinx XST vs FPGA Express?
The guy said he will tell you how to do it if you sent him an E-mail (I
suppose it would have been better if he posted more information about it
to the newsgroup).
Before you get Xilinx's PCI LogiCORE licensed, you may want to
play around with a free evaluation version of PCI LogiCORE.
To do so, do a search of their website with keywords, "IP Evaluation".
The evaluation version should come with a VHDL netlist, so you can throw
this into XST and see what happens.
Although I am not sure, I believe the evaluation version doesn't come
with a UCF file to constrain the LUT locations, so even if you can
synthesize it correctly with XST, it will likely not meet 33MHz PCI's
setup time (Tsu < 7ns) requirement.
I guess that's how Xilinx get people to license it after the evaluation.
If you know how to use Floorplanner to force a LUT to a certain location
of the chip, you may be able to floorplan it to meet 33MHz PCI's setup
time requirement.
Kevin Brace (don't respond to me directly, respond within the newsgroup)
Peter van Beek wrote:
>
> Hello everybody,
>
> Currently I am doing some investigation for an appropriate PCI
> solution. We want to implement an application that is able to send 32
> bits data (with a rate of 25 Mhz) to the PCI bus. This will be done by
> means of an FPGA, using the VHDL design flow. We're doing some
> evaluation with a Xilinx Spartan II PCI demo board. The VHDL design
> flow is supported by WebPACK ISE.
>
> The most common way turns out to be using LogiCore. Unfortunaly
> synthesizing LogiCore is not supported by ISE. I don't have much
> insight in this process, can somebody tell me what exactly happens
> during synthesizing. Also suggestions about which compiler to use are
> welcome.
>
> Are there any other options except using LogiCore? Maybe an off the
> shelf solution that already contains a stand alone PCI interface
> (maybe at other companies).
>
> Best regards,
>
> Peter van Beek
> design engineer
> Zevenaar Elektronica en Sensoren
> Arnhem, The Netherlands
> (31)263653393
Article: 38077HI, Peter Alfke <palfke@earthlink.net> wrote: > Matthias Weber wrote: >>> i am searching for a link, book, university lessons explaining the >> architecture of asic and fpga and their differences. > > Matthias, the differences are not so much in the architecture as in the > economics. ASIC means IC for a specific purpose. FPGA is a posibility to do so. Normaly you mean cellbased designs when talking about ASIC, but FPGA are also ASIC. Peter Alfke means cellbased (I guess *g*). The architecture of FPGA is major devided in two Families RAM based like Xilinx and antifusebased like Actel. See their homepages for architectural details. > That's why more and more designers prefer the FPGA solution that does > not have these high up-front costs and long waiting time, and can be > bought in any quantity at any time, and be modified ad infinitum. > State-of-the-art ASICs have very high NRE costs, while old-fashioned > ASICs are cheaper, but offer no real performance advantage over FPGAs. > I admit to being biased, but the trend is clearly in favor of FPGAs. Another point is the size of your design. First there is a limit to maximum size available for FPGA, than you come very cheap using really small FPGA. So a rule of thump says the more gates you need, the more your like to use cellbased. The number of identical ASICs is also very important, Depending on who you talk with, and what ASICs they need, you get something between 50 and a few thousand ACSICs as the border to switch from ASIC to FPGA. bye Thomas -- Thomas Stanka BC/EMD4 Space Communications Systems Tesat Spacecom GmbH & Co KG thomas.stanka@de.bosch.comArticle: 38078
Thanks for replying, We want to stick to the 32 bit, 33 Mhz bus. Our data is not sustained but consist of bursts that can vary between 16 Kbyte and 64 KByte. We consider using extern memory to avoid time critical situations. Any suggestions regarding this matter? Regards, PeterArticle: 38079
Kenneth <small__lee@hotmail.com> wrote: > In UCF, I set the timing constraint for the 50MHz input clock > (bclk_in) which is > NET "bclk_in" TNM_NET = "bclk_in"; > TIMESPEC "TS_bclk_in" = PERIOD "bclk_in" 20 ns HIGH 50 %; Kenneth, possibly PAR and or TRCE is making a mistake when propagating your PERIOD specific through the two DCMs. You could put a PERIOD constraint on the clk_4x signal directly. Hopefully that will override the automatically generated constraint. > But I feel stange that why for the clock signal clk_4x, > the timing report shows that > Source Clock: clk_4x rising at 7.500ns > Destination Clock: clk_4x rising at 10.000ns > while it should be 5ns between 2 rising edges. Unfortunately I don't understand why it shows you clk_4x rising at 7.5 and 10ns. TRCE's behaviour is sometimes very mysterious! regards Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 38080
Why not use an older Spartan-II instead? It supports 5V tolerant I/Os. Kevin Brace (don't respond to me directly, respond within the newsgroup)Article: 38081
Doug wrote: > I need to interface some old-fashioned 5V logic to a Spartan-IIE FPGA, > which has 3.3V I/O. > > I know I could use something like a 74LVX3245, but apparently it can > be safely done with resistors as well. In the appnote "Spartan-IIE > Family: Frequently Asked Questions" (Xilinx document #FAQ100), it > says: > > "The Spartan-IIE is 3.3V I/O compatible and will only support 5.0V > I/Os when an external pull-up resistor is used." > > ...and that's all the info I've been able to find so far. > and it is, in fact, slightly misleading. There are 2 parts to getting 5V compatibility with 3V3 devices: o Output: The devices receiving signals from the FPGA have to have a Vih(min) <= the FPGA's Voh(min). For most modern TTL-compatible devices this is o.k. but you'll have to be careful if there are any true CMOS 5V parts. This is sort of where the ``pull-up'' comes in but there are better/cleaner ways of doing this. o Input: Here the problem is that no Virtex class devices except for the original Virtex familiy are 5V tolerant. There are 2 approaches you can take to this: - Xilinx state that a 100R between the 5V source and the FPGA pin is sufficient. - Use QuickSwitch type buffers between the 5V domain and the FPGA. For something like 5V PCI the QS approach is much less electrically intrusive although it costs more in PCB real estate. These magic devices are really a bunch of FET switches whose impedance is about 5-10R (with a max Tpd of 250ps) until the driving side gets to about 0V7 below VCC. From then on the impedance increases very steeply. For the 5V QS parts the trick is/was to power them from a supply in the 3V3-3V9 range. There are now 3V3 versions of these parts but BE WARNED: They come in 2 flavours - clamping and non-clamping.Article: 38082
"Markus Meng" <meng.engineering@bluewin.ch> schrieb im Newsbeitrag news:aaaee51b.0201032258.66a971cd@posting.google.com... > Hi all, > > By the way actel has some nice FPGA's in the FBGA package. The 256FBGA is > really small and well suited for PCMCIA cards. Does Xilinx or Altera If you mean a 256 balls package with 1 mm pitch, then yes, there are lots of different FPGAs available from Xilinx. -- MfG FalkArticle: 38083
"Jason Berringer" <jberringer@trace-logic.com> schrieb im Newsbeitrag news:IJ5Z7.12027$A67.3131096@news20.bellglobal.com... > > library ieee; > use ieee.std_logic_1164.all; > use ieee.std_logic_unsigned.all; > > entity counter is > generic(width : integer := 32); > port( > clk : in std_logic; > cnt_clr : in std_logic; > cnt_enable : in std_logic; > reset : in std_logic; > cnt_out : out std_logic_vector(width-1 downto 0) > ); > end counter; > > architecture RTL_counter of counter is > > signal countL : std_logic_vector(cnt_out'range); > > begin > > P1: process (reset, cnt_clr, clk, cnt_enable) begin > if (reset = '1' or cnt_clr = '0') then > countL <= (others => '0'); > elsif (rising_edge(clk)) then > if (cnt_enable = '1') then > countL <= countL + 1; > end if; > end if; > end process; > > cnt_out <= countL; > > end RTL_counter; As far as I can see, this simple ce'ed counter should run @100 Mhz, even in a Spartan-II-5. Just compile the counter alone and look at the timing report. It should clearly say tha clk can be faster than 10ns. Often, the timing analyzer is doing wiered things (not at all, false paths are more the problem here) and it looks like the circuit is too slow. -- MfG FalkArticle: 38084
> We want to stick to the 32 bit, 33 Mhz bus. Our data is not sustained > but consist of bursts that can vary between 16 Kbyte and 64 KByte. We > consider using extern memory to avoid time critical situations. Any > suggestions regarding this matter? Is your data rate really 100M bytes/sec... If so, I do not believe you will be able to sustain this rate. As you suggest, putting buffer memory on the board, so you reduce your PCI bus requirement, may be your only solution if you want to be on a 32/33 PCI bus. Are you transfering to system memory? Are you the only activity that will be going on? Is this a dedicated system, or a standard Windows based PC?Article: 38085
Andreas Schweizer <mail@andreas-schweizer.de> wrote in message news:<3C33D64A.5D38B5C2@andreas-schweizer.de>... > Jason Berringer wrote: > > > The tools report that the maximum > > frequency is about 67 MHz. Does this mean that this counter will not work > > correctly, > > A 32-bit counter is quite long, so you should consider implementing it in > severals stages as look-ahead counters. > Even using a divide by two prescaler would work. In your 100 MHz counter, the LSB changes state at 100 MHz. The other bits change state at 50 MHz, 25 MHz and so on. You just have to treat the lowest bits as a special case.Article: 38086
Is it bad design practice to use a multiplexor to switch clocks. I have a design which seems to work ok where I select a 30 MHz clock at on time and then switch to a 16 MHz clock later. The maximum speed of the D/A I am feeding is 17MHz when fed serial data but I can load my parallel to serial converter at the higher frequency and then shift the data at the slower rate. Thanks in advance. CWArticle: 38087
Hi all, I would like to know how much time is necessary after finishing, compiling etc. the design to actually load it into the device. Maybe someone can tell me a value like ms/CLB or something. An actual value of a specific FPGA would be also helpful. I'm not a FPGA designer, but currently I'm working with a reconfigurable hardware architecture, where a new configuration just needs a few clock cycles to be loaded. I would like to know the value for FPGAs just for comparison. Therefore even a raw estimation would be good. Thanks in advance, Claus RitterArticle: 38088
Doug, The recommendation is to use a 100 ohm resistor in series with the 5V driver output to the 3.3V powered IO bank on the Spartan IIE. This way, if the driver can pull all the way to 5V, the forward clamping of the input diode to Vcco limits the voltage at the input pin to Vcco+0.5V (the diodes are intrinsic to the pmos output fets which are present in the IOB, so they are ~ 0.5V drop). If you first simulate the connection in IBIS, you may find that the 5V outputs are classic TTL (not CMOS), and can not pull above Voh(max) of a voltage that does not exceed Vcco+0.5V (i.e. less than 3.8 V). If this is the case, no resistor is needed to limit the input current into the Spartan IIE. Many TTL parts that are CMOS used nmos pull-up transistors in the output stage, so the Voh(max) was always ~ 0.7 V below the Vcc of 5V, or lower. If placing a 100 ohm resistor in series slows down the signal too much, one can also simulate it in IBIS with a resistor to ground. A 75 ohm resistor, for example, will load down the driver without slowing down the signal, resulting in a lower Voh(max). Remember to simulate the fast/strong corner in IBIS, as that is the cold/strong transistor/high vcc case that will be the worst case. Also then simulate the slow/weak corner to be sure the voltages are still within spec for the input to see 0's and 1's. Innoveda's Hyperlynx has a free download version that can be used for these kinds of what if's. The demo version can not import new IBIS files, and has other restrictions, but I highly recommend trying it out. Once you get using it, you will be hooked, and just buy the real version. The cost will save board respins due to bad SI, so you will end up saving money the first time you use it. For those of you with the Cadence, or Mentor IBIS simulator tools, those are also excellent, and I highly recommend them. Avant! Hspice also imports IBIS as a subcircuit model, so it can be used for those who like spice. Austin Lesea ICDES Xilinx Doug wrote: > I need to interface some old-fashioned 5V logic to a Spartan-IIE FPGA, > which has 3.3V I/O. > > I know I could use something like a 74LVX3245, but apparently it can > be safely done with resistors as well. In the appnote "Spartan-IIE > Family: Frequently Asked Questions" (Xilinx document #FAQ100), it > says: > > "The Spartan-IIE is 3.3V I/O compatible and will only support 5.0V > I/Os when an external pull-up resistor is used." > > ...and that's all the info I've been able to find so far. > > Before I proceed, I would like to see more specific recommendations > (preferably from Xilinx!) about how best to do this. Is anyone out > there aware of any other documents detailing Xilinx' recommended > method, specifically for the Spartan-IIE family? > > Thanks in advance, > > Doug JonesArticle: 38089
"Claus Ritter" <ritter@fzi.de> schrieb im Newsbeitrag news:a14hph$i2i@absalom.fzi.de... > Hi all, > > I would like to know how much time is necessary after finishing, compiling > etc. the design to actually load it into the device. > Maybe someone can tell me a value like ms/CLB or something. > An actual value of a specific FPGA would be also helpful. This times can be easyly calculated using the datasheets. For the newer Xilinx parts (Spartan-II and better) , in parallel configuration mode (8 bit) the maximum clock frequency is 50 MHz (without handshaking). The configuration files range from 100kbits (smallest Spartan-II, 15k gates) to 33Mbits (biggest Virtex-II, 10M gates). The reset should be primary school math. ;-) The numbers are not 100% correct since I dont have the datasheets at my fingertips now. -- MfG FalkArticle: 38090
"Chuck Woodring" <c.woodring@worldnet.att.net> schrieb im Newsbeitrag news:wjjZ7.324393$W8.12424509@bgtnsc04-news.ops.worldnet.att.net... > Is it bad design practice to use a multiplexor to switch clocks. I have a > design which seems to work ok where I select a 30 MHz clock at on time and > then switch to a 16 MHz clock later. The maximum speed of the D/A I am > feeding is 17MHz when fed serial data but I can load my parallel to serial > converter at the higher frequency and then shift the data at the slower > rate. So I would use just 30 MHz and generate a 15 Mhz clock enable signal (just a toggle FF) for the A/D converter section. Makes the design simpler and more reliable. -- MfG FalkArticle: 38091
> Hi all, > > I would like to know how much time is necessary after finishing, compiling > etc. the design to actually load it into the device. > Maybe someone can tell me a value like ms/CLB or something. > An actual value of a specific FPGA would be also helpful. > > I'm not a FPGA designer, but currently I'm working with a reconfigurable > hardware architecture, where a new configuration just needs a few clock > cycles to be loaded. I would like to know the value for FPGAs just for > comparison. Therefore even a raw estimation would be good. > > > Thanks in advance, > Claus Ritter > > Typically look at the size of the configuration area, and then how many can be loaded in parallell at what speed. Using a serial configurator running at 33 MHz and 521 kbit configuration info (Atmel AT40K40) it should totally reconfigure in 16 milliseconds. Of course you can do partial reconfiguration and reconfigure a single CLB in a few microseconds. If you run in parallell mode, it will be a lot faster. The hard part about partial reconfiguration is how to do good place & route tools for it. -- Best Regards Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Sweden.Article: 38092
In article <wjjZ7.324393$W8.12424509@bgtnsc04-news.ops.worldnet.att.net>, c.woodring@worldnet.att.net (Chuck Woodring) wrote: > Is it bad design practice to use a multiplexor to switch clocks. Depends on how important it is that the circuit works, I suppose :-) > I have a > design which seems to work ok where I select a 30 MHz clock at on time > and then switch to a 16 MHz clock later. If you could make it 32 and 16, and switch synchronously, your life would be a lot easier. If you could use just one clock and a synchronous clock-enable, it would be easier still. As it is, you have to decide what you want to do when both clocks are transitioning at 'about' the same time. If it doesn't matter that the circuit will see runt pulses that could trigger metastability and cause invalid outputs, then don't worry (but don't go boasting about it!) Otherwise, your best bet is probably to resync the slower clock to the faster with the standard pair of registers in series. This will screw up the clock's duty cycle, of course, so I hope that's not important. -- Steve Rencontre http://www.rsn-tech.co.uk //#include <disclaimer.h>Article: 38093
Hi - On Fri, 04 Jan 2002 14:51:08 GMT, "Chuck Woodring" <c.woodring@worldnet.att.net> wrote: >Is it bad design practice to use a multiplexor to switch clocks. I have a >design which seems to work ok where I select a 30 MHz clock at on time and >then switch to a 16 MHz clock later. The maximum speed of the D/A I am >feeding is 17MHz when fed serial data but I can load my parallel to serial >converter at the higher frequency and then shift the data at the slower >rate. Yes, it's a bad idea. Unless the implementation is absolutely impeccable, a clock multiplexer circuit can produce glitches that will drive you crazy. From your description above, it's not clear to me why using two clocks is helping you. If the problem is that you have a large block of circuitry running at 30 MHz and a small shifter running at 16MHz, and you want to transfer parallel load data from the 30MHz domain to the 16MHz domain, you're better off building a synchronizer. Metastability and synchronization haves been discussed extensively in past threads. Or, if you can afford the speed hit, run the shifter at 15MHz by feeding it the 30MHz clock and enabling it every other cycle, and dispense with the synchronizer for the parallel load. Some of the newer Xilinx parts have clock multiplexers with glitchless switchover. I don't use them (the muxes, not the parts). > >Thanks in advance. >CW > Bob Perlman -- Cambrian Design Works digital design, signal integrity http://www.cambriandesign.comArticle: 38094
Hello. I am trying to reverse-engineer an old supercomputer front-panel display. It contains many xilinx FPGA's. The part number is Xilinx: XC3042(tm) -100 PQ100C date codes, etc. it is in a many-pinned gull-wing PQFP on the xilinx web site, the XC3000 series seems to be discontinued. I am looking for old datasheets, etc. Does anyone know if the XC3000A series is pin, bitfile, etc. compatible? In other words, if I compile a design for the XC3042A, will it work with these devices? Thanks! devArticle: 38095
In article <3C353149.1A7CDD1A@earthlink.net>, palfke@earthlink.net says...
> If you have infinite amounts of money and time, and never make a mistake
> and never intend to change your design, then ASICs are great ( Low price
> per chip, high performance, low power). But this comes at a high price
> in non-recurring engineering charges ( $1 000 000 for a state-of-the art
> big circuit ) and it takes months to get the first chip. And you must
> always order and pay for a specific quantity, and never make a mistake
> or a change.
>
> That's why more and more designers prefer the FPGA solution that does
> not have these high up-front costs and long waiting time, and can be
> bought in any quantity at any time, and be modified ad infinitum.
All of this seems a bit overstated. Here's another perspective perhaps
overstated in the other direction. You don't need infinite time and money to do
an ASIC (I'll address mistakes in a minute). ASICs generally cost less per part
but have an upfront NRE cost and longer lead time. So if your volume is large
and you can afford the lead time, it often makes economic sense to go with an
ASIC. There is typically a volume crossover point where on one side an FPGA is
cheaper and on the other side an ASIC is cheaper.
As you mentioned, state of the art ASICs perform better than state of the art
FPGAs and can be much lower power so performance or power may require you to use
an ASIC. ASICs offer much more flexability with regard to what you can do;
while FPGAs have gotten very flexible, they are no where near as flexible as an
ASIC with respect to different kinds of I/O drivers, pin placement, multiple
PLLs, DLLs and clock domains, varieties of internal memories, etc. Custom ASICs
offer even more flexibility and performance than standard ASICs allowing you
construct your circuits at the transistor level. Even standard ASICs allow you
map to just about any set of gates that you want for your circuit whereas
designs in FPGAs must be mapped into whichever lookup tables, cells and math-
assist resources are available in the target FPGA. Floorplanning is important
for both ASICs and FPGAs but there can be more floorplanning headaches in FPGAs
which pay a higher penalty if logic feeds other logic that is not close by ("off
row" or whatever). In ASICs a slightly longer wire is just slightly more delay
-- it scales much better.
I would also argue that design source written for ASICs is much more portable
and reusable than design source written for FPGAs. This is because FPGA designs
(especially math functions) must be structured to map well to the particular
FPGA architecture it is targeted for or a performance penalty (sometimes severe)
will be paid. When porting the design to a different FPGA, the design may have
to be rearchitected. Targeting an ASIC design to another ASIC technology is
often just a case of resynthesis to the new library. Sometimes the netlist can
be ported avoiding even the resynthesis.
With regard to not being able to make a mistake when designing an ASIC and
FPGA's being able to "be modified ad infinitum": Being able to modify an FPGA
is great during product development but doesn't do as much good after a product
has shipped. If people buy a video card with an FPGA on it and that FPGA has a
bug, those people are usually in the same boat that they would be in if the card
had used an ASIC instead. They are (usually) not going to be able to reprogram
that FPGA at home so both the FPGA designer and the ASIC designer need to get
the design right by ship time. During development time, mistakes are worse for
ASICs but they are not as bad as some FPGA proponents would have you believe.
ASICs commonly go through two or three passes and each pass is not a full respin
of all the work, time and money needed to make the first part. In fact many
second passes are ECs to the existing mask which preserve all of the design,
synthesis, floorplanning, layout, wiring and timing work that has already been
done.
--
Rich Iachetta
iachetta@us.ibm.com
I do not speak for IBM.
Article: 38096I think this is the formula: Time to configure = [(number of config bits)/((configuration frequency)*(bits/clock))] + Tpor Number of config bits can be found in the datsheets Configuration frequency and number of bits per clock (parallel vs. serial) is dependent upon your configuration method. Tpor is the time for power on reset, also spec'ed in the datasheet. If you are reconfiguring after a pulse of the PROG pin then use Tpl instead Chris Claus Ritter wrote: > Hi all, > > I would like to know how much time is necessary after finishing, compiling > etc. the design to actually load it into the device. > Maybe someone can tell me a value like ms/CLB or something. > An actual value of a specific FPGA would be also helpful. > > I'm not a FPGA designer, but currently I'm working with a reconfigurable > hardware architecture, where a new configuration just needs a few clock > cycles to be loaded. I would like to know the value for FPGAs just for > comparison. Therefore even a raw estimation would be good. > > Thanks in advance, > Claus RitterArticle: 38097
Kevin Brace <nospamtomekevinbraceusenet@nospamtomehotmail.com> writes: > A few months ago, there was a guy who claimed that he figured out how to > synthesize (technically synthesizing is not the correct word, processing > a netlist should be correct) Xilinx's PCI LogiCORE with XST. > To retrieve the past posting I am talking about, try doing a Google > Groups search (http://groups.google.com/groups?group=comp.arch.fpga) for > comp.arch.fpga "only" with the following titles. > > Xilinx PCI core and XST > > Xilinx XST vs FPGA Express? > > The guy said he will tell you how to do it if you sent him an E-mail (I > suppose it would have been better if he posted more information about it > to the newsgroup). The specific messages can be found at the URLs: http://groups.google.com/groups?selm=9r8vkh%24pp1%241%40proxy2.fe.internet.bosch.com and http://groups.google.com/groups?selm=9rb28l%24mbt%241%40proxy2.fe.internet.bosch.comArticle: 38098
--------------A80D1CD33C21574980A87D7C Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit dev wrote: > I am looking for old datasheets, etc. > > Does anyone know if the XC3000A series is pin, bitfile, etc. > compatible? In other words, if I compile a design for the XC3042A, > will it work with these devices? No, see below. For the data sheets, click on: http://www.xilinx.com/partinfo/3000.pdf The Xilinx data book states ( and I wrote it ): "XC3000A is an enhanced version of the basic XC3000 family., featuring additional interconnect resources and other user-friendly enhancements." You can pour an XC3000 bitstream into an XC3000A device, and it will work perfectly. The reverse is obviously not true. The additional features in XC3000A use "spare" configuration bits that were not used in the XC3000, but any XC3000 would not know what to do with the extra bits in the spare location. Peter Alfke, Xilinx ApplicationsArticle: 38099
"Richard Iachetta" <iachetta@us.ibm.com> wrote in message > With regard to
not being able to make a mistake when designing an ASIC and
> FPGA's being able to "be modified ad infinitum": Being able to modify an
FPGA
> is great during product development but doesn't do as much good after a
product
> has shipped. If people buy a video card with an FPGA on it and that FPGA
has a
> bug, those people are usually in the same boat that they would be in if
the card
> had used an ASIC instead. They are (usually) not going to be able to
reprogram
> that FPGA at home so both the FPGA designer and the ASIC designer need to
get
> the design right by ship time. During development time, mistakes are
worse for
> ASICs but they are not as bad as some FPGA proponents would have you
believe.
> ASICs commonly go through two or three passes and each pass is not a full
respin
> of all the work, time and money needed to make the first part. In fact
many
> second passes are ECs to the existing mask which preserve all of the
design,
> synthesis, floorplanning, layout, wiring and timing work that has already
been
> done.
Richard,
I hear what you are saying, but I thought I would clarify one point.
In the product that I am presently developing, which is an enhanced version
of something out in the field, the FPGAs are configured by microprocessor.
This allows us to update the FPGA programming quite easily. Whenever the
client company wants to do a software update, which is shipped to the field
via Internet or CD, the FPGA programming is included. Therefore, FPGAs can
be easily updated out in the field if the hardware to allow this is planned
in advance.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL USA
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