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
Let's stick with English, otherwise we have ro rename this the "FPGAinformationsaustauschzentralverteilungsstelle". All presently existing S3-50s lack the BlockRAM and therefore the DLLs ( BlockRAM and DLL share a column. When we took out one, we had to take out the other). The decision was made in order to speed up the design, and was then reversed, so all future production 50's will have BlockRAMs and DLLs. The existing S3-1000s of course have DLLs and BlockRAMs. Everybody using these "Early Silicon" devices MUST consult the errata sheet. By definition, ES always has an errata sheet ( in the best case it would just say "no errata"). Peter Alfke, Xilinx Applications =============================== Mike Randelzhofer wrote: > > "> Hab auch ein paar S3-50 in der Schublade... > Weiss aber immer noch nicht ob die Blockrams und DLL's haben oder nicht ? > > Gruss MIKE > > for our english readers: > I also have some spartan3-50 devices, but don't know if they have blockrams > and dll's ? > > regards MIKEArticle: 57501
Mike Randelzhofer <michael.randelzhofer@mchf.siemens.de> wrote: : Hab auch ein paar S3-50 in der Schublade... : Weiss aber immer noch nicht ob die Blockrams und DLL's haben oder nicht ? : Gruss MIKE : for our english readers: : I also have some spartan3-50 devices, but don't know if they have blockrams : and dll's ? To my knowledge, the first batch of 3S50 was made without BRAM and DLLs. Try to decipher the Date Code and you probably you'll find information on the Xilinx webpage ( and you probably will get feedback here). Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 57502
Hi, There are a number of boards available. You should look for a server class motherboard, one that supports PCI-X or at least PCI at 66 MHz. A board that supports either of those will be (by requirement) at 3.3v slot, not a 5.0v slot. If you are looking for a cheap machine that will do the job, you may consider the HP Kayak XU800. I see a number of them available on Ebay from time to time. Eric Colin Hall wrote: > > Dear All, > > Apologies if this is slightly off-topic but I hope there may be > someone reading who has faced a similar problem. > > I have a prototype 33/32 PCI peripheral. The PCI bus interface is > implemented in a Spartan-IIE device, which is not +5V tolerant. Design > verification of the hardware is underway on this new design. > > I would like to make progress on software development while we wait > for the hardware to be finished. To that end, I am looking for a > PC-architecture motherboard into which I can plug our prototype card > without blowing the Spartan-IIE device. > > I tried searching for suitable commodity motherboards. There are > plently of boards but none of them specified that their PCI bus > interfaces were 3.3V only. > > If anyone can suggest a suitable board I would be most grateful. > > Regards, > Colin.Article: 57503
"Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag news:3F01C8E9.9E79F922@xilinx.com... > Let's stick with English, otherwise we have ro rename this the > "FPGAinformationsaustauschzentralverteilungsstelle". OK, but i didn't know that this NG is called "FPGAinformationexchangecentraldistributioncenter". > > All presently existing S3-50s lack the BlockRAM and therefore the DLLs ( > BlockRAM and DLL share a column. When we took out one, we had to take > out the other). The decision was made in order to speed up the design, > and was then reversed, so all future production 50's will have BlockRAMs > and DLLs. So the present s3-50 devices without blockrams are the fastest s3 90nm chips forever ? MIKEArticle: 57504
On 1 Jul 2003 05:47:25 -0700, lecroy7200@chek.com (lecroy) wrote:
>I am reposting after a memo from reader siting problems using the
>Xilinx link to post to this group. Sorry about any problems this may
>have caused.
Thanks, I appreciate the lack of HTML in the news group.
>After the release of Alliance 3 support was no longer offered
>for the XC3xxx family. Worse, if you did not happen to
>have the original software that supported these
>devices, Xilinx would not sell you a copy. Even today we
>still have product that uses the 3xxx family.
At least for XC4000E, EX, XL, XLA, and Spartan, the SW is
available as Xilinx "Classic" software (free, but need normal
xilinx user id/password).
http://www.xilinx.com/webpack/classics/spartan_4k/index.htm
>I am looking at upgrading our group to Allience 5.x
>and again see that Xilinx has dropped all support for
>Spartan. Other families were dropped as well. We would
>now need three copies of software running to
>support the Xilinx devices we use. Of course, not all
>the Xilinx tools like to be co-installed, so it's multiple
>computers or swap installs.
As for maintaining multiple versions of the software
on the same computer, I have found that VMWARE (www.vmware.com)
is a very good solution. I basically set up a virtual computer
for each version of the software, and each is kept separate
and there are no conflicts. Costs a few GBytes of disk, which
these days is only a few $.
Philip Freidin
Philip Freidin
Fliptronics
Article: 57505> You can feel how you wish about your designs, but even the loss of the > 64 bit dual ports and the 128 bit single port rams is not signficant. > To make a 64 bit dual port RAM requires 8 LUTs for ram (same as in VII) > and one LUT for the read mux and possibly two more LUTs for the WEs. > But if this is part of a larger ram block you are making half of the WEs > would have been required anyway. So it is not a "large" amount of > logic, just a bit more. Ok, I agree with you, it´s not to much logic. But because these extra delays maybe I have to duplicate the circuits. > If you are making really large blocks where the longer runs on the > address and data can slow it down significantly, then you likely are > better off with the block rams. No, they are not large blocks, but I have 128 to 512 FIR filters (256 coefs) running in parallel, and the sampling rate is 2 megaHertz. Throughput! > Considering the much lower price of the XC3S parts, all this sounds to > me like a benefit, not a liability. Think of it as paying for the LUTs > that have RAM and getting the other LUTs for free :) I'm not complaining, and I know that Xilinx wil not make a special Spartan3 just for me. But I have the right to express what I think, and maybe I'm not alone. Maybe there are a lot of Luizes and Rays, maybe Xilinx will hear us and maybe, at these nanometer scales where the pads are so big, to have all the CLBs configurable as memory is not so significant in silicon area. Luiz Carlos Oenning Martins KHOMP SolutionsArticle: 57506
Matt, You must register through the link at the end of the app note (after reading the disclaimer). You will then receive a email with a link to the HDL code. Hope that helps, Steve mduane@umich.edu wrote: > Does anyone know where I can find the xapp354_verilog or xapp354_VHDL > files for NAND flash? I went to the Xilinx ftp site, and they were > not listed there. Thanks.--MattArticle: 57507
The question is simply, can the Spartan-3 support the PLB GeMAC at this time? I found in the Spartan-3 FAQ that it WILL support 1 Gig Ethernet MACs but I couldn't tell where in the future the WILL was pointing to. Thanks for any insight, JimArticle: 57508
already5chosen@yahoo.com (Michael S) wrote in message news:<f881b862.0307010229.563153f@posting.google.com>... > sdatta@altera.com (Subroto Datta) wrote in message news:<ca4d800d.0306301212.1cd9be9c@posting.google.com>... > > already5chosen@yahoo.com (Michael S) wrote in message news:<f881b862.0306300619.58b3f8a5@posting.google.com>... > > > Following PLL was generated with MegaWizard Plug In Manager and > > > compiled (for Stratix) under Quartus 2.2: > > > Input Frequency: 36MHz > > > Dynamic reconfiguration is in use. > > > c0 Clock Multiplication Factor = 158 > > > c0 Clock Division Factor = 36 > > > Other counters are not in use. > > > The compilation report shows: > > > M value = 79 > > > N value = 3 > > > VCO frequency = 948MHz !!!! > > > It looks like Quartus design team is not aware of limitations of the > > > Stratix PLL as listed in the respective datasheet (300 to 800MHz for > > > -5 and -6 grades, 300 to 600MHz for -7 grade). They live under > > > impression that everything up to 1000MHz is o.k. :( > > The Stratix Fast PLL can go up to 1GHz for certain speedgrades, which > > is why the Megawizard allows this (only the Enhanced PLL is limited to > > 800Mhz). A design that needs a VCO at 1GHz will work in Stratix. The > > PLL will then be placed on the Fast PLL and be used as a general > > purpose PLL. However a Fast PLL cannot be used for dynamic > > reconfiguration, and this should have been reported during fitting. > > > > For Quartus II version 3.0, the Megawizard has been enhanced to > > recognize that only an Enhanced PLL can be used when dynamic > > reconfiguration is selected, and as a result it will ensure that the > > VCO is valid for an Enhanced PLL in the Megawizard itself. The > > Megawizard will become speedgrade aware in a future release of > > Quartus. In the meantime all calculations are based on the fastest > > speedgrade. > > > > - Subroto Datta > > Altera Corp. > > > > > > I don't have Quartus II version 3.0 (BTW, is it already available ?) > so can't comment about it. What I do know - Quartus II version 2.2 > Megawizard doesn't emit "enhanced" set of PLL parameters, so the > Megawizard has no direct control of the VCO frequency. Unless it was > changed in the 3.0, I can't see how improvements in the Megawizard > would fix the problem. IMHO, the bug is in the compiler and it's where > it should be fixed. > In the mean time, the only reliable solution I can think of is: > 1. Don't use the Megawizard. > 2. Manually set enhanced parameters for the altpll(). > It would work, of coarse, but it's a PITA... > > Regards, > Michael In Stratix devices there are two types of PLLs - Enhanced PLLs and Fast PLLs. The Megawizard performs a feasibility check to make sure the resulting parameters the compiler will compute (including the VCO frequency) will be valid for at least one of these PLL types. For Quartus II 3.0, the Megawizard is aware of the restriction that forces the use of Enhanced PLLs when using reconfiguration, and as a result will make sure all parameters can be implemented in an Enhanced PLL earlier on in the flow. But even in Quartus II 2.2, the compiler will give an error if the PLL cannot be implemented in either of the PLL types, including if no set of internal parameters could achieve the requested PLL settings and a legal VCO for the speed grade selected. If a legal set of internal parameters did exist that could achieve the requested PLL settings, then the compiler will implement those parameters. Quartus II 3.0 was released to production/manufacturing on June 27th so you should be seeing it real soon. - Subroto Datta Altera Corp.Article: 57509
Can anyone provide feedback on Celoxica. Do they meet all of the claims? Performance obtained ? Pros and cons?Article: 57510
"M.Randelzhofer" wrote: > > So the present s3-50 devices without blockrams are the fastest s3 90nm chips > forever ? No, when I wrote "speed up", I meant weeks in design, not picoseconds in operation. Spartan3 is not the fastest, in some areas it is slower than Virtex-II, since the priorities for Spartan3 were: 1. low cost, 2. low cost, and 3. low cost. We don't throw away speed, but we did not increase the chip size to gain performance. Deleting BRAM and DLL does nothing to the performance, but it reduced the design effort, and it made the chip smaller. But this is all history now. "FPGAinformationsaustauschzentralverteilungsstelle" was meant as a joke, referring to the American fascination with the German capability to concatenate words ad infinitum. Donaudampfschifffartgesellschaftskapitaen.... Peter Alfke Peter AlfkeArticle: 57511
Quartus II 3.0 was released to production this past Friday, June 27. As I am an "insider" and don't wait for the install CDs to be delivered, I can't give an accurate date of when they will be mailed out, but an educated guess would be within a couple of weeks. If you have a more urgent need, I reccomend contacting your local Altera FAE or Sales office and explain the need for Flex compilation support with Nios - sometimes its possible to have them burn a CD or setup an FTP download for you. Regards, Jesse Kempa Altera Corp. jkempa at altera dot com > > When is Quartus version 3 coming out? > > > Hi, > My sources tells me late June worst case early August. (They are > allready posting app notes on new features on Alteras homepage!) > /Fredrik > >Article: 57512
Xilinx has two major product lines. Virtex is for performance and features, Spartan is for low cost. Otherwise, the architectures are very similar. That gives us a chance to really optimize each line. The Spartan developers reduce the cost, accepting that this makes their devices non-optimal for certain applications, but there is always Virtex to deliver higher functionality and performance (at a higher price). The Virtex designers can optimize functionality and speed, knowing that this might increase the cost, but there is always Spartan to satisfy less performance-critical, but more cost-sensitive applications. There is no free lunch, in engineering almost everything is a trade-off. But everybody still asks for champagne on a beer budget :-) Peter Alfke ======================= Luiz Carlos wrote: > > > I'm not complaining, and I know that Xilinx wil not make a special > Spartan3 just for me. But I have the right to express what I think, > and maybe I'm not alone. Maybe there are a lot of Luizes and Rays, > maybe Xilinx will hear us and maybe, at these nanometer scales where > the pads are so big, to have all the CLBs configurable as memory is > not so significant in silicon area. > > Luiz Carlos Oenning Martins > KHOMP SolutionsArticle: 57513
Hi all I have questions about bitstream relocation in VirtexII FPGAs. We have already developed software based on the old Jbits package from Xilinx for doing small bits manipualations bitstream relacation for Virtex devices, but we are facing difficulties in finding documentation about how to perform significant-size IP-core bitstreams (50,000 gates or more) relocation in VirtexII devices. Can you give some hint on where such documentation can be found, if it exists? We are implementing a configurations controller manager in hardware, to allow automated swap of IPs in a number of identical size reconfigurable areas defined using the Modular Design flow (even though the current documentation suggests that it is complicated to make things work with more than one reconfigurable area at the same time, we have managed to define and "almost" use 2 such areas). The idea is: given a temporal schedule for reconfigurable IPs and apply this using the ICAP interface to partially reconfigure the device in one of the areas. Having more than one area is fundamental to allow bitstream prefetch for hiding reconfiguration latency. Thanks in advance for any help. Ewerson L. S. Carvalho, Master Student - Informatics Institute, PUCRS Mail Address: Av Ipiranga, 6681, Prédio 16. Porto Alegre, RS, Brazil CEP:90619-900 - Phone:+55 51 3320 3611 - Fax:+55 51 3320 3758 e-mail: ecarvalho@inf.pucrs.br - URL: http://www.inf.pucrs.br/~ecarvalhoArticle: 57514
I've ask Xilinx the ? about legacy support for years -- I have the same problem with XC4005 series -- we have hundreds fielded on MILITARY applications. However Xilinx newer tool suites Foundation/Alliance DO NOT support these legacy devices. So we are STUCK with maintaining an OLD machine with OLD Xilinx XACT software. lecroy wrote: > I am reposting after a memo from reader siting problems using the > Xilinx link to post to this group. Sorry about any problems this may > have caused. > > After the release of Alliance 3 support was no longer offered > for the XC3xxx family. Worse, if you did not happen to > have the original software that supported these > devices, Xilinx would not sell you a copy. Even today we > still have product that uses the 3xxx family. > > I am looking at upgrading our group to Allience 5.x > and again see that Xilinx has dropped all support for > Spartan. Other families were dropped as well. We would > now need three copies of software running to > support the Xilinx devices we use. Of course, not all > the Xilinx tools like to be co-installed, so it's multiple > computers or swap installs. > > Xilinx, what is your problem? Altera may drop parts, but > their router continues to support all of their devices. > Is your software so poorly written that it is so difficult > to maintain parts that you need to drop them? I could understand > if the parts were no longer available, or you at least sold > older copies of your software.Article: 57515
A seminar on "Digital Signal Processing, Programmable Device
Architecture, and Military/Aerospace Applications" will be presented at
the 2003 MAPLD International conference on September 8th, 2003, in
Washington, D.C.
http://www.klabs.org/richcontent/MAPLDCon03/tutorials/
Abstract
========
Digital signal processing has traditionally been done using Von-Neuman
or Harvard type processors with enhancements such as single cycle
multiplies. Recent advances in speed, density, and features have made
Field Programmable Gate Arrays (FPGAs) very attractive for digital
signal processing applications, particularly when performance
requirements are beyond the capability of microprocessors.
Unfortunately, the majority of signal processing work over the last
quarter century has been implemented as software on computers.
Consequently, there is currently very little overlap between hardware
design and DSP expertise. Algorithms developed for software platforms
are usually very inefficient for direct hardware implementation, and
without the overlapping areas of expertise, the resulting FPGA
realization is bound to disappoint.
This seminar helps to bridge the gap between DSP and FPGA design, aiding
the designer in achieving the performance potential of FPGAs. This
seminar will first review computer arithmetic and then look in detail at
efficient FPGA implementations of common DSP elements such as
multipliers, filters, and mixers. Tradeoffs between clock rate and
performance will be discussed along with several design examples.
Conference home page: http://klabs.org/mapld03
Additional info: Richard B. Katz, NASA Office of Logic Design
richard.b.katz@nasa.gov
Article: 57516Please make sure that you are using the latest Xilinx Implementation tools. From the previous message I can see that you are using 5.1. The latest tools are 5.2i with service pack 3. When looking at the schematics for the ML300 you will see that the FPGA PROG button goes to the corresponding pin on the FPGA, i.e. pushing the button will clear out the contents of the FPGA. - Peter tk wrote: > Hi all, > > I have problem in configuring the xc2vp7 on the ML300 board. The > problem is described in the previous thread "ERROR:iMPACT:583". > > I doubt that I have omitted some settings on the ML300 board during > programming (or have done sth wrong in iMPACT). There is a button > called "FPGA PROG" on the ML300 board. I've searched through the > documentation but I couldn't find out what's it for. > > Does anyone have the experience on using ML300 that can share with me ? > > Thanks very much. > > tkArticle: 57517
i want to use some ARM C/C++ compiler which is independent of the operating system. What i am looking for is plain translation of my C/C++ benchmarking code into plain ARM assebly and then into binaries... if i use the ADS C/C++ compiler it generates some software interrupts which kinda throws everything off track... Did any one have the same problem before...? or shoudl i get started with writing my own ARM compiler (but would take ages (: ) Thanks KartikArticle: 57518
Jon Terje Haugland wrote: > I am designing a DDR SDRAM controller in a Virtex-II 1500 -5 FFA896. > It should operate at 166 MHz towrads the DDR SDRAM. I have used > XAPP266 as reference regarding the timing analysis towards the DDR > SDRAM. In XAPP266 one of the "results" is: > 0.503ns<tDQS-tDQ<1.025 (midpoint at 0.76ns). This delay is introduced > by routing? If the PCB delay is 180ps pr. inch. it would require a DQS > net that is 4.2 inches? Is this correct??? Yes, this is correct. This delay is the difference between the DQ line length on the PCB and the DQS line length on the PCB. If the DQ lines are 1.5 inches, the DQS lines need to be 1.5 inches + 4.2 inches = 5.7 inches, assuming 180ps/inch. The delay of the PCB varies with stackup, use care. Delay of vias can be significant, make sure the number and placement of vias match or that this delay is included in the calculation. -- Phil HaysArticle: 57519
Greetings,
I am having a strage time with some code I recently wrote to implement a UART - the code is working fine now, but a problem cropped up that is baffling me. This design is being synthesized in
Xilinx ISE 5 and implemented into a Spartan-II XD2S50 device. I'm on something of a learning curve with things right now so please go easy on me! :D
when 10 => -- Stop Bit
BitPos := 11; -- next is holding pattern for breaks
if(FIFOhead = 3) then
FIFOhead := 0; -- wrap around
else
FIFOhead := FIFOhead + 1;
end if;
FIFO(FIFOhead)(8) <= RxD; -- stash the break bit
FIFO(FIFOhead)(7 downto 0) <= RReg; -- stash the received data
The two FIFO array assignment statements at the bottom are the predominant problem.... The object is to assign the break bit to the 9th bit of the array of 9-bit words (indexed by the process
variable 'FIFOhead'), and then assign the databyte to the lower part. As written and synthesized, the above writes ONLY the received byte and NOT the break bit. If the statements are
exchanged, the opposite happens. In short, only the SECOND assignment appears to be executing properly. If a 'dummy' statement is inserted, so the code looks like:
............
end if;
FIFO(FIFOhead)(7 downto 0) <= RReg; -- stash the received data
FIFO(FIFOhead)(8) <= RxD; -- stash the break bit
FIFO(FIFOhead)(7 downto 0) <= RReg; -- stash the received data
then both assignments work properly. There appears to be some amount of latency inherent in updating the variable before it can be used as an index, but why? And what is the proper way to
detect or circumvent this problem? This fix works temporarily just fine, but I fear this problem may explain similarly strange behavior in other sections of code. If this IS a latency problem, how
should I go about detecting these sort of things in my design to ensure all code is relatively bulletproof? All of the VHDL texts I have here really only cover language theory and simulation
synthesis, not the perils of things like proper floorplanning of the design. What's the best way to work on filling in the learning gaps? Thanks in advance for any insight!
-- Matt
Article: 57520"rickman" <spamgoeshere4@yahoo.com> wrote in message news:3F00FDD2.C74022BD@yahoo.com... > "Nicholas C. Weaver" wrote: > That is a good point about the tools. I forget that the XC3S is only > supported in webpack in the XC3S50 now and I think only up to the > XC3S400 in the next release. I honestly don't get the idea of selling > very low cost chips and not adding them to the free tools. Personally, I agree with your statement and have been trying to convince the powers that be to add additional Spartan-3 devices to WebPack. The folks responsible for WebPack are concerned about the total download size. The larger devices have multi-MB support files. > But good luck getting a price on the XC3S1000 at this point. The > XC3S1000 parts have been pushed back due to design problems and will not > be out until Q1 or perhaps later. The XC3S400 and one of the larger > parts will be out in 4Q03 according to their schedule. Hmm. Engineering samples of the XC3S1000 and XC3S50 are available today. The engineering samples have the part number XC3S1000J and XC3S50J to distinguish them from the production devices. This may be the reason you were quoted longer delivery. The non-'J' devices are due out in 4Q2003. The non-'J' version of the XC3S50 also includes block RAM, embedded multipliers, and 2 Digital Clock Managers (DCMs), which the XC3S50J does not. -- --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/II/IIE FPGAs http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=Spartan-3 Tel: (408) 626-7447 E-mail: steve.knapp@xilinx.com ---------------------------------Article: 57521
Steven K. Knapp wrote: > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:3F00FDD2.C74022BD@yahoo.com... > > "Nicholas C. Weaver" wrote: > > That is a good point about the tools. I forget that the XC3S is only > > supported in webpack in the XC3S50 now and I think only up to the > > XC3S400 in the next release. I honestly don't get the idea of selling > > very low cost chips and not adding them to the free tools. > > Personally, I agree with your statement and have been trying to convince the > powers that be to add additional Spartan-3 devices to WebPack. The folks > responsible for WebPack are concerned about the total download size. The > larger devices have multi-MB support files. You could always shock them with the 'left field' concept of selective downloading just the device library files you need ? :) -jgArticle: 57522
Peter Alfke wrote: > > rickman wrote: > > > > > > Except that I often am contacted by Altera directly rather than here in > > public. I can understand why they would do that. > > I cannot understand that at all. If the question is ventilated in > public, it should be answered in public. Unless the answer is very embarrassing... > > Peter Alfke, Xilinx Often vendors don't want to seem like they are hawking their wares here. So I see nothing wrong with contact on a more personal level in order to get a good answer to a question. When your sales people make calls on customers, they don't invite the competition to come along do they? Support is no different. Why should the open the door for kibitzing from the competition? And maybe they will be revealing some information that they don't want the competition to have. I know that Xilinx has been pretty tightlipped about their product schedules. At least I have had a very hard time getting that info until a couple of weeks ago when I insisted that I needed it on the Spartan 3s. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 57523
Luiz Carlos wrote: > > > You can feel how you wish about your designs, but even the loss of the > > 64 bit dual ports and the 128 bit single port rams is not signficant. > > To make a 64 bit dual port RAM requires 8 LUTs for ram (same as in VII) > > and one LUT for the read mux and possibly two more LUTs for the WEs. > > But if this is part of a larger ram block you are making half of the WEs > > would have been required anyway. So it is not a "large" amount of > > logic, just a bit more. > > Ok, I agree with you, it´s not to much logic. But because these extra > delays maybe I have to duplicate the circuits. > > > If you are making really large blocks where the longer runs on the > > address and data can slow it down significantly, then you likely are > > better off with the block rams. > > No, they are not large blocks, but I have 128 to 512 FIR filters (256 > coefs) running in parallel, and the sampling rate is 2 megaHertz. > Throughput! > > > Considering the much lower price of the XC3S parts, all this sounds to > > me like a benefit, not a liability. Think of it as paying for the LUTs > > that have RAM and getting the other LUTs for free :) > > I'm not complaining, and I know that Xilinx wil not make a special > Spartan3 just for me. But I have the right to express what I think, > and maybe I'm not alone. Maybe there are a lot of Luizes and Rays, > maybe Xilinx will hear us and maybe, at these nanometer scales where > the pads are so big, to have all the CLBs configurable as memory is > not so significant in silicon area. Yes, certainly you have the right to express your views and to let Xilinx know what you need. But I think you are responding to the idea that "something" is missing without knowing for sure if it is really an issue. When you say above that adding the level of logic may slow down the design, you first need to know how fast these parts run. After all, you are comparing 90 nm Spartan 3s to 150 nm VirtexIIs. It is very possible that the S3s will run faster even with the added delays. I am sorry if my "nagging" is annoying. But I have watched a lot of changes in FPGAs and have often felt they were not for the better. But somewhere around the Virtex or VirtexII parts I started to realize that I needed to forget about how the parts were different and focus on how to solve my design problems using them. With that I have come to understand that often what I saw as a limitation is more than made up for in other areas. I am sure that Xilinx does not remove functionality without considering the trade offs very seriously. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 57524
Peter Alfke wrote: > > Xilinx has two major product lines. Virtex is for performance and > features, Spartan is for low cost. Otherwise, the architectures are very similar. > > That gives us a chance to really optimize each line. The Spartan > developers reduce the cost, accepting that this makes their devices > non-optimal for certain applications, but there is always Virtex to > deliver higher functionality and performance (at a higher price). > The Virtex designers can optimize functionality and speed, knowing that > this might increase the cost, but there is always Spartan to satisfy > less performance-critical, but more cost-sensitive applications. > > There is no free lunch, in engineering almost everything is a trade-off. > But everybody still asks for champagne on a beer budget :-) > Peter Alfke I am not looking for champagne on a beer budget, but I would sure like to be able to pour them both into the same glass. That is I would like to have one footprint that I an put a Spartan into for low cost or a Virtex when I need high performance and large size. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
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