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
marc_ely <marc_ely@yahoo.co.uk> wrote: >I took the plunge and built up a 2nd PC using a Core2Duo. >Here are the specs: >Old PC: P4 3GHz HT, 2GB DDR2-533 RAM, Gigabyte GA81915 mobo, stock >cooler >New PC: Core2Duo E6600, 2GB DDR2-800 RAM, ASUS P5B Mobo, ArcticFreezer7 >cooler >Using a Spartan3 design running clean from scratch in ISE 8.2.3i >Old PC: 82mins >New PC: 35mins >New PC (overclocked to 3.2GHz): 25mins >I'm really pleased with the Core2Duo and would recommend it. Conclusion dual cores (multiprocessor) benefits Xilinx ISE substantially?Article: 111476
Terry, Thanks for your reply. It looks like you're right. I used the EDK to generate the makefiles, then corrected the home directory line to read: XILINX_EDK_DIR = /cygdrive/c/EDK_82 Then saved the make files under a new name. I then set the project to use these files and all is now happy. I think I'll do this rather than roll back make, and wait for Xilinx to correct the makefiles produced by the EDK ;) Thanks, Peter tbrown wrote: > If you have kept up your cygwin distribution, it is likely this problem is > caused by the newer version of make that gets installed. I don't remember > the version numbers for the newer versions, but if you back up to make > version 3.80, it will probably work. > > The problem has to do with supported characters in paths in the version of > make. > > If you are writing your own makefiles, in some cases you can get around > the problem by using cygpath to generate compatible paths. > > Terry BrownArticle: 111477
helmut.leonhardt@gmail.com wrote: >Everything what can parallelize is possibly running faster in Hardware >than in Software. Still, the amount of processing power a modern PC processor can deliver is enormous. It is problably more cost effective to optimize an algorithm to run parallel on 10 PC's than to develop a specific FPGA solution. If space is a constraint, the answer is in using blade servers. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 111478
PeteS wrote: > > The only engineering maxim is do it right in the minimum space and > minimum cost, although those two can conflict. > Actually the engineer's goal is to nail function (get it to do the right thing), performance (perform the function at the right speed) and cost (be able to produce it for a price that it can the be sold at for a profit). 'Minimum space' (or any measure of space) is a design constraint that one must live with (among a whole slew of others) not a goal to be optomized. KJArticle: 111479
I would say that: function, performance, availability, cost, size and ease of use are all considerations, the first three usually absolute. The relative importance varies with the application. There can be cases (like rickman's?) where pc-board size is a dominating requirement, more important than anything else. But that is an unusual case... Peter Alfke On Nov 3, 9:22 am, "KJ" <Kevin.Jenni...@Unisys.com> wrote: > PeteS wrote: > > > The only engineering maxim is do it right in the minimum space and > > minimum cost, although those two can conflict.Actually the engineer's goal is to nail function (get it to do the > right thing), performance (perform the function at the right speed) and > cost (be able to produce it for a price that it can the be sold at for > a profit). > > 'Minimum space' (or any measure of space) is a design constraint that > one must live with (among a whole slew of others) not a goal to be > optomized. > > KJArticle: 111480
Sorry for my unclear explanation. Using your simplification with 64 bits my goal is to do the following chain of full 64 additions (for example 3 operations a 64 bit): BA [DSP #1; A:B ] + DC [DSP #1; C] + FE [DSP #2, A:B] <<--- takes PCIN from DSP #1 + HG [DSP #3, A:B] <<--- takes PCIN from DSP #2 -------- (Z)YX [3, P] I assume three cascaded DSP slices to perform the computations. The statement in square brackets remark the index of the respective DSP slice which takes the computation on the left and its I/O port in which the data chunk is fed. In the first cycle, I planned to start adding T1=A+C using DSP #1 and pass on the result T1 to DSP #2 via PCIN. In the next cycle, DSP #2 computes T2=T1+E and passes the result to DSP #3. At the same time, DSP #1 can already start to compute R1=B+D (pipelining) and so on... The problem with this approach is that I probably can't use the carry logic in the dedicated silicon since the DSP #1 is using C input for the Z mux and #2 and #3 the PCIN causing the carry being generated from a previous result. I guess my architecture is not optimal for the use of the DSPs but there are some constraints on the availability of the 32bit input chunks which become accessible after a certain period of time. Thus I cannot freely choose where to start with my computations (chunks become available in alphabetic order A-B-C-D-E...) I am appreciating any ideas which help me to avoid using a carry generated and routed through the fabric ;-) Thanks again, Ben. Cheers, Tim Ben Jones schrieb: > Hi Tim, > > "Tim" <gueneysu@crypto.rub.de> wrote in message > news:1162565977.101678.102780@i42g2000cwa.googlegroups.com... > > Ben, thanks so much! This is the kind of solution I am looking for! > > > > But just one litte question: I am dealing with a situation which > > requires me to add several 256bit numbers in a row. Hence, I planned to > > use a serial design of several interconnected DSP slices each caring > > for a single 256 addition computing a 32 bit chunk at a time. I > > intended to pass on the first 32bit chunk from one DSP slice to the > > next using the PCOUT/PCIN path. > > I'm not sure I quite understand what you are doing. > > Let's simplify and look at a 64-bit addition, done in two halves. > Representing each 32-bit chunk by a letter, you want to do: > > BA > +DC > --- > =YX > > To do this in two stages, first you add A to C and get X and a carry. Then > you add B to D with the carry and get Y (and a final carry which we'll > ignore). So, once you've done the first step, you already have the > least-significant 32 bits of the result (X) - and they play no further part > in the computation. So, why do you need to use the PCOUT path for anything > (other than the carry, if you intend to do the Y=B+D computation in the next > DSP block up)? > > Maybe I've misunderstood your algorithm a bit. > > Cheers, > > -Ben-Article: 111481
>>I took the plunge and built up a 2nd PC using a Core2Duo. > >>Here are the specs: >>Old PC: P4 3GHz HT, 2GB DDR2-533 RAM, Gigabyte GA81915 mobo, stock >>cooler >>New PC: Core2Duo E6600, 2GB DDR2-800 RAM, ASUS P5B Mobo, ArcticFreezer7 >>cooler > >>Using a Spartan3 design running clean from scratch in ISE 8.2.3i >>Old PC: 82mins >>New PC: 35mins >>New PC (overclocked to 3.2GHz): 25mins > >>I'm really pleased with the Core2Duo and would recommend it. > > Conclusion dual cores (multiprocessor) benefits Xilinx ISE substantially? > No, cache size matters.... As far as I know, neither ISE nor Quartus use the second core, but both benefit from the huge cache. Thomas www.entner-electronics.comArticle: 111482
Nico Coesel wrote: > helmut.leonhardt@gmail.com wrote: > > >Everything what can parallelize is possibly running faster in Hardware > >than in Software. > > Still, the amount of processing power a modern PC processor can > deliver is enormous. It is problably more cost effective to optimize > an algorithm to run parallel on 10 PC's than to develop a specific > FPGA solution. If space is a constraint, the answer is in using blade > servers. > This is often true even for obvious applications of FPGA, PC can still be better. The analysis needs to account for factors such as floating point use, high locality referencing or lots of computing on tiny data sets and use of standard 32, 64 bit operands favors PCs On the other hand bit mangling, very high rates of memory shuffling, use of unusual bit wise or odd size mathematical operators and strategic use of buffer memories are a win for FPGAs. I suspect that as Flash drives replace hard drives at the 30GByte level the case for hardware taking control of data management in Flash only increases since a hardware FPGA design wouldn't usually include disk systems and can then push the PC host further away. Some problems can be factored both ways to get similar results in which case PCs still have the familiarity edge. Still a PC based solution that is just recompiled to hardware will perform far less well since it has already been factored to favor the PC. For a hardware solution, the software version can be viewed as the simulation of same hardware and most simulations usually run many orders slower than real hardware. This is why the best hardware solution is unlikeley to ever be achieved by software folks who have little experience in hardware who would force the FPGA to emulate the PC strengths. John Jakson transputer guyArticle: 111483
The other area where FPGA's win is in latency. Parallel or networked PC's cannot meet the latency requirements of many large computationally intensive real-time systems, even though they can meet the throughput requirements Marco ________________________ Marc Reinig UCO/Lick Observatory Laboratory for Adaptive Optics "JJ" <johnjakson@gmail.com> wrote in message news:1162578053.176232.266200@e3g2000cwe.googlegroups.com... > > Nico Coesel wrote: >> helmut.leonhardt@gmail.com wrote: >> >> >Everything what can parallelize is possibly running faster in Hardware >> >than in Software. >> >> Still, the amount of processing power a modern PC processor can >> deliver is enormous. It is problably more cost effective to optimize >> an algorithm to run parallel on 10 PC's than to develop a specific >> FPGA solution. If space is a constraint, the answer is in using blade >> servers. >> > > This is often true even for obvious applications of FPGA, PC can still > be better. > > The analysis needs to account for factors such as floating point use, > high locality referencing or lots of computing on tiny data sets and > use of standard 32, 64 bit operands favors PCs On the other hand bit > mangling, very high rates of memory shuffling, use of unusual bit wise > or odd size mathematical operators and strategic use of buffer memories > are a win for FPGAs. > > I suspect that as Flash drives replace hard drives at the 30GByte level > the case for hardware taking control of data management in Flash only > increases since a hardware FPGA design wouldn't usually include disk > systems and can then push the PC host further away. > > Some problems can be factored both ways to get similar results in which > case PCs still have the familiarity edge. Still a PC based solution > that is just recompiled to hardware will perform far less well since > it has already been factored to favor the PC. > > For a hardware solution, the software version can be viewed as the > simulation of same hardware and most simulations usually run many > orders slower than real hardware. > > This is why the best hardware solution is unlikeley to ever be achieved > by software folks who have little experience in hardware who would > force the FPGA to emulate the PC strengths. > > John Jakson > transputer guy >Article: 111484
Laurent Pinchart wrote:
> Is there any proper simulation solution for the Linux platform ?
Quartus FLOATLNX $3k license covers linux modelsim
for vhdl or verilog. This would cover functional
simulation, but probably no backanno for models
other than Altera.
-- Mike Treseler
Article: 111485Thanks for the speedy reply everyone, I appreciate the help. ~Lance On Nov 3, 10:26 am, "Marc Reinig" <M...@newsgroups.nospam> wrote: > The other area where FPGA's win is in latency. Parallel or networked PC's > cannot meet the latency requirements of many large computationally intensive > real-time systems, even though they can meet the throughput requirements > > Marco > ________________________ > Marc Reinig > UCO/Lick Observatory > Laboratory for Adaptive Optics > > "JJ" <johnjak...@gmail.com> wrote in messagenews:1162578053.176232.266200@e3g2000cwe.googlegroups.com... > > > > > Nico Coesel wrote: > >> helmut.leonha...@gmail.com wrote: > > >> >Everything what can parallelize is possibly running faster in Hardware > >> >than in Software. > > >> Still, the amount of processing power a modern PC processor can > >> deliver is enormous. It is problably more cost effective to optimize > >> an algorithm to run parallel on 10 PC's than to develop a specific > >> FPGA solution. If space is a constraint, the answer is in using blade > >> servers. > > > This is often true even for obvious applications of FPGA, PC can still > > be better. > > > The analysis needs to account for factors such as floating point use, > > high locality referencing or lots of computing on tiny data sets and > > use of standard 32, 64 bit operands favors PCs On the other hand bit > > mangling, very high rates of memory shuffling, use of unusual bit wise > > or odd size mathematical operators and strategic use of buffer memories > > are a win for FPGAs. > > > I suspect that as Flash drives replace hard drives at the 30GByte level > > the case for hardware taking control of data management in Flash only > > increases since a hardware FPGA design wouldn't usually include disk > > systems and can then push the PC host further away. > > > Some problems can be factored both ways to get similar results in which > > case PCs still have the familiarity edge. Still a PC based solution > > that is just recompiled to hardware will perform far less well since > > it has already been factored to favor the PC. > > > For a hardware solution, the software version can be viewed as the > > simulation of same hardware and most simulations usually run many > > orders slower than real hardware. > > > This is why the best hardware solution is unlikeley to ever be achieved > > by software folks who have little experience in hardware who would > > force the FPGA to emulate the PC strengths. > > > John Jakson > > transputer guyArticle: 111486
John_H wrote: > <rponsard@gmail.com> wrote in message > news:1161898879.404939.234850@b28g2000cwb.googlegroups.com... > > see > > http://www.digilentinc.com/Products/Detail.cfm?Prod=S3E1600&Nav1=Products&Nav2=Programmable > > Woo Hoo ! _And_ it apparantly has Stepping 1 silicon. Thanks for the > heads-up. Thanks to OP for the info. I received my kit from Digilent yesterday. (What's different about stepping 1?) It _is_ very spartan -- it ships with exactly: the board, a power dongle, and a usb cable. The board runs a little self-test upon power on, but I'm a bit concerned that the regulator chip gets burning hot, in fact the area in a 1cm radius looks burned! Even though the Digilent page and the schematics claim 32 MiB, it features a 64 MiB DDR SDRAM, just like the regular Spartan 3E starter kit. My only disappointment is the very minimal documentation and the complete lack of a pre-cooked constaint file. The pin assignment is different from the regular Spartan 3E starter kit, so you can't just reuse the constaints from there, assuming you could locate a comple description for that. I started building my own based on the schematics, but it seems completely crazy that every user would have to go though this pain. Even then, what are the IO standards supposed to be? In the Xil3S500E_Serial_Flash_v81, the sys_clk_in is given as LVCMOS33 where as most every else it's given as LVTTL? Does it not matter? Thanks, TommyArticle: 111487
rickman wrote: >>The issue with the smaller packages is insufficient cavity size, and in >>many cases I guess not enough pins to make it widely appealing. > > > That is what Xilinx is always saying. But they put the XC2C128 and > XC2C256 parts in very fine pitch, small packages (8x8 mm CP132), so > clearly the die size vs. package size is not the issue. I just can't > use parts with balls on 0.5 mm pitch. I can use a 48 pin QFP which is > only 1 mm larger on the board at 9 mm sq or a LFBGA100 with 100 pins > and 10 mm sq footprint. I don't need a pin for every macrocell. If > Xilinx applied the same logic to the FPGAs with a pin per logic cell, > would we need packages with 100,000 pins and up? There is certainly scope for CPLDs in smaller packages. What would be your preferred package and pin count for a compact 128 Macrocell device ? Xilinx have done some QFNs for the smaller CPLDs, but I think they stopped at 64MC ?. Did you mention what you wanted, and why they lost the sale, to them? Packages are relatively cheap (a new package is way cheaper than a new die development), give them a large enough volume target, and they will chase it. > I wonder if Xilinx would consider their pins to have 12.5% more > functionality than their competitor's pins? They might :) IIRC Atmel have Pinkeep/Pullup/Schmitt/OD/GND programmable on a per pin basis, whilst lattice have only global Pullup. One could argue that makes the Atmel pin 20% smarter than the lattice one :) [Tho more likely, the lattice drawback would kill a very low power design stone dead, as one pins current pull-up is way higher thanthe Static Iq) -jgArticle: 111488
Hello all, Some time ago with an older version of the EDK (v6 I think) there was a ML300 design that would simulate the entire SoC, and included a hook into a local terminal window that would talk over the simulated SoC rs232 serial port. For example, you could build a system in the EDK that runs an executable on the PPC that would echo the characters it receives over RS232. That i/o was provided through an actual terminal window on the simulation system, and some how that real i/o was converted to the simulated RS232 framing. I'm currently dealing with a Spartan 3E Starter kit, and would like to simulate my system using this simulated rs232 terminal hook. Does this kind of feature still exist with the 8.2 EDK? Thanks, AnthonyArticle: 111489
Thomas Entner wrote: > >>I took the plunge and built up a 2nd PC using a Core2Duo. > > > >>Here are the specs: > >>Old PC: P4 3GHz HT, 2GB DDR2-533 RAM, Gigabyte GA81915 mobo, stock > >>cooler > >>New PC: Core2Duo E6600, 2GB DDR2-800 RAM, ASUS P5B Mobo, ArcticFreezer7 > >>cooler > > > >>Using a Spartan3 design running clean from scratch in ISE 8.2.3i > >>Old PC: 82mins > >>New PC: 35mins > >>New PC (overclocked to 3.2GHz): 25mins > > > >>I'm really pleased with the Core2Duo and would recommend it. > > > > Conclusion dual cores (multiprocessor) benefits Xilinx ISE substantially? > > > No, cache size matters.... As far as I know, neither ISE nor Quartus use the > second core, but both benefit from the huge cache. > > Thomas > > www.entner-electronics.com Not just regular L2 cache but the TLB or address cache matters even more I suspect but harder to characterize and explain. When the data set is still beyond even the bigger combined cache of a Dual, the increase in associative ways of the bigger TLB kicks in to reduce the incidence of the OS having to refill MMU page tables which can blow ns cache hits into several 100ns accesses for full cache miss. I ran a test on an older 2GHz Athlon XP2400 and a 2.6GHz D805 for a loop that just randomly accesses ints from a 512MB array using a mask to control the variability of address from 256 ints to the 128M max and for each case run the loop 1M times. I believe this represents the worst possible behaviour of any CAD application that must traverse huge graphs or trees that can not fit cache but easily fit DRAM. The D805 generally runs 30% faster as the clock suggests while the tests are entirely cache bound but the Athlon has 256K of L2 with 256 ways in the TLB. The 805 has 1MB of L2 in each core and I expect the TLB has 1k ways of associativity. Only 1 core is used. I expect the CoreDuo or 64b Athlons to perform somewhat better. For in cache times the loop iterates in 7ns or 10ns resp for D805 v xp2400. As the range of addresses increases past 64K the Athlon staircases to 60ns then out around 2M degrades to 80ns-150ns and at 128M range settles at 400ns per iteration over the original 10ns or 40 times slower to crawl memory. The D805 fairs some better, it tolerates another 2b of address but degrades to 60ns at 256K level then reaches 130ns at the 128M level. In other words when the L2 cache always misses, the D805 spends far less time patching up the TLB and MMU page tables. The D805 runs Windows2k with 1GB of DDR400 and the Athlon runs BeOS on 1GB of DDR266 but thats not real important. Conclusion is that paying for bigger TLBs is probably far better than more cpus since it just keeps the uni processor closer to its ideal performance for codes that have poor locality of reference. Adding more cores probably makes things worse as the quad core shows unless code is really multithreaded. John Jakson transputer guyArticle: 111490
KJ wrote: > "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message > news:454aba2d$1@clear.net.nz... > >>When faced with these 'edicts' you need to get creative :) > > And I'll give you that...you did get 'creative' suggesting number of unblown > fuses as a metric of usage....on a device that probably doesn't have 'fuses' > since it's likely EEPROM based, so what you're really suggesting is a metric > of how many 'spare' '0's (or '1's) there are to be written into the > device....not very useful, but no doubt creative. Would be interesting to > try that metric and see how many people nod their head in agreement. Close - I use 'fuse' terminology since that's what the programmer reports. Typical examples: Blow Count: 8254, on a 16808 Sized device Largest I can find, is Blow Count: 15851, (94.3%) which is a somewhat rare design that has 100.0% PT usage. This design reports a fanin usage of 85%. In this case (device family/programmer), the Blow count roughly tracks (just under) PT% usage, I think because in these devices a free PT row, is 'do nothing' in the fuse array. > > I agree with the gist of it, conjure up a metric that can dazzle the easily > dazzled if they are the ones holding you back. > > >>In a PLD vs full hardware implementation, then pin resource does not >>need 40% headroom, as clearly the connectors etc do not have that. >> >>So, you can look at the product-terms and that should come better than 40% >>spare. > > This one actually can be a decent metric. -jgArticle: 111491
axalay ha scritto: > If this distanse is 70 mm may I hope that the devise is work correctly? > And may I do not connect terminate resistor beetwin Rx- and Rx+ ? You have to look at the rise time (tR) and fall time of your signals. My rule of thumb is that if distance D > (2/3)c tR; than you need terminations. There are tons of documents on the subject.Article: 111492
Marc Reinig wrote: > The other area where FPGA's win is in latency. Parallel or networked PC's > cannot meet the latency requirements of many large computationally intensive > real-time systems, even though they can meet the throughput requirements > > Marco Ofcourse, whipping up a quick list of platform benefits bound to miss some obvious ones. Also both platforms continually changing/improving but also getting harder to understand and less transparent. That alone makes it harder to compare since one mans optimized code is another mans starting point. Still the basic decider is likely to be whether one knows how to even start a FPGA. project. > ________________________ > Marc Reinig > UCO/Lick Observatory > Laboratory for Adaptive Optics > > > "JJ" <johnjakson@gmail.com> wrote in message > news:1162578053.176232.266200@e3g2000cwe.googlegroups.com... > > > > Nico Coesel wrote: > >> helmut.leonhardt@gmail.com wrote: > >> > >> >Everything what can parallelize is possibly running faster in Hardware > >> >than in Software. > >> > >> Still, the amount of processing power a modern PC processor can > >> deliver is enormous. It is problably more cost effective to optimize > >> an algorithm to run parallel on 10 PC's than to develop a specific > >> FPGA solution. If space is a constraint, the answer is in using blade > >> servers. > >> > > > > This is often true even for obvious applications of FPGA, PC can still > > be better. > > > > The analysis needs to account for factors such as floating point use, > > high locality referencing or lots of computing on tiny data sets and > > use of standard 32, 64 bit operands favors PCs On the other hand bit > > mangling, very high rates of memory shuffling, use of unusual bit wise > > or odd size mathematical operators and strategic use of buffer memories > > are a win for FPGAs. > > > > I suspect that as Flash drives replace hard drives at the 30GByte level > > the case for hardware taking control of data management in Flash only > > increases since a hardware FPGA design wouldn't usually include disk > > systems and can then push the PC host further away. > > > > Some problems can be factored both ways to get similar results in which > > case PCs still have the familiarity edge. Still a PC based solution > > that is just recompiled to hardware will perform far less well since > > it has already been factored to favor the PC. > > > > For a hardware solution, the software version can be viewed as the > > simulation of same hardware and most simulations usually run many > > orders slower than real hardware. > > > > This is why the best hardware solution is unlikeley to ever be achieved > > by software folks who have little experience in hardware who would > > force the FPGA to emulate the PC strengths. > > > > John Jakson > > transputer guy > >Article: 111493
martstev@gmail.com wrote: > I am using Altera Stratix II FPGA and also power supervisor circuit > which generates reset which it tied to nCONFIG for configuration of > the FPGA. Now, I'd like to generate RESET for the FPGA after the > configuration and Initialization is complete everytime. I can't find a > part that can do that..any suggetions? If you are reconfiguring the part on reset, why do you want to reset the design again? The design will come up in the "reset" state after configuration. Perhaps I'm missing something, but it seems redundant to async reset an FPGA right after configuration?Article: 111494
axalay wrote: > If this distanse is 70 mm may I hope that the devise is work correctly? > And may I do not connect terminate resistor beetwin Rx- and Rx+ ? > I am currently using on SFP module at a distance of 71 mm. I don't use external termination resistors, if that is what you mean.Article: 111495
Jim Granville wrote: > rickman wrote: > >>The issue with the smaller packages is insufficient cavity size, and in > >>many cases I guess not enough pins to make it widely appealing. > > > > > > That is what Xilinx is always saying. But they put the XC2C128 and > > XC2C256 parts in very fine pitch, small packages (8x8 mm CP132), so > > clearly the die size vs. package size is not the issue. I just can't > > use parts with balls on 0.5 mm pitch. I can use a 48 pin QFP which is > > only 1 mm larger on the board at 9 mm sq or a LFBGA100 with 100 pins > > and 10 mm sq footprint. I don't need a pin for every macrocell. If > > Xilinx applied the same logic to the FPGAs with a pin per logic cell, > > would we need packages with 100,000 pins and up? > > There is certainly scope for CPLDs in smaller packages. > > What would be your preferred package and pin count for a > compact 128 Macrocell device ? I am still hearing that "intellegence" is wanted on the module. So I might suggest that we can combine a small MCU with a small CPLD and keep the intelligence on board with a higher power consumption. But this just seems like such over kill. If I could get the 128 MC device in a 48 pin TQFP which is only 9 mm sq including the leads, that would do the entire job other than the IO conditioning and relay drive. > Xilinx have done some QFNs for the smaller CPLDs, but I think > they stopped at 64MC ?. Exactly. > Did you mention what you wanted, and why they lost the sale, to them? This is business that both Altera and Xilinx pursue agressively. They are totally in the loop on every project we do because the volumes are high and we don't really beat them too hard on price. I only found out about this particular win because I was there for a X presentation where they discussed the large packages with our system engineers. > Packages are relatively cheap (a new package is way cheaper than > a new die development), give them a large enough volume target, > and they will chase it. That is not what X and A will tell you. They plan out the packaging when they design a product family. It seems to be a major issue to put a part in a new package. Otherwise they would be selling 5000 more units a month for the next 7 years or so. > > I wonder if Xilinx would consider their pins to have 12.5% more > > functionality than their competitor's pins? > > They might :) > IIRC Atmel have Pinkeep/Pullup/Schmitt/OD/GND programmable on > a per pin basis, whilst lattice have only global Pullup. Atmel vs. Lattice? What type of parts are you talking about? > One could argue that makes the Atmel pin 20% smarter than the > lattice one :) > [Tho more likely, the lattice drawback would kill a very low power > design stone dead, as one pins current pull-up is way higher thanthe > Static Iq) I have not worked with the Altera Cyclone II parts yet, but the Spartan 3 parts have an interesting feature where you can kill all the pullups on the User IOs during configuration. But you can't eliminate the pullups on the configuration pins no matter what. Combine that with the stiffness (down to 1 kohm) and you have IOs that can't be programmed with a resistor to ground and then easily overdriven once the design is loaded. I think you need about a 330 ohm resistor to drive it low enough. Then driving it high with an output takes nearly 10 mA! Some CMOS outputs are only rated for 4 mA drive.Article: 111496
"JJ" <johnjakson@gmail.com> wrote: > >Marc Reinig wrote: >> The other area where FPGA's win is in latency. Parallel or networked PC's >> cannot meet the latency requirements of many large computationally intensive >> real-time systems, even though they can meet the throughput requirements >> >> Marco > >Ofcourse, whipping up a quick list of platform benefits bound to miss >some obvious ones. > >Also both platforms continually changing/improving but also getting >harder to understand and less transparent. That alone makes it harder >to compare since one mans optimized code is another mans starting >point. > >Still the basic decider is likely to be whether one knows how to even >start a FPGA. project. For any serious project this shouldn't be an issue. Last year I needed to warp video in real time to project video on an odd shape. It turned out a PC was more than fast enough for this task. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 111497
rickman wrote: > Jim Granville wrote: >>Packages are relatively cheap (a new package is way cheaper than >>a new die development), give them a large enough volume target, >>and they will chase it. > > > That is not what X and A will tell you. They plan out the packaging > when they design a product family. It seems to be a major issue to put > a part in a new package. Of course, salesmen will always pitch what they have, and give all sorts of spin as to why anything else should be off your radar :) When we spoke with infineon years ago, they said ~50K was enough to contemplate a new package. If it is one already in their flow, that helps as well. So, for Xilnix that means probably the QFN48. Then they think about OTHER customers, and something like this is NOT a blind alley, as there are many applications for CPLDs with more macrocells, but less IO. Then, it's a simple die bonding question, but QFN packages have large paddle areas. To help focus them, ask about bare die MOQs ? > Otherwise they would be selling 5000 more > units a month for the next 7 years or so. so you mean appx 420,000 is the expected volume ? >>>I wonder if Xilinx would consider their pins to have 12.5% more >>>functionality than their competitor's pins? >> >>They might :) >>IIRC Atmel have Pinkeep/Pullup/Schmitt/OD/GND programmable on >>a per pin basis, whilst lattice have only global Pullup. > > > Atmel vs. Lattice? What type of parts are you talking about? The ATF1502BE vs ispMACH4032Z >>One could argue that makes the Atmel pin 20% smarter than the >>lattice one :) >>[Tho more likely, the lattice drawback would kill a very low power >>design stone dead, as one pins current pull-up is way higher thanthe >>Static Iq) > > > I have not worked with the Altera Cyclone II parts yet, but the Spartan > 3 parts have an interesting feature where you can kill all the pullups > on the User IOs during configuration. But you can't eliminate the > pullups on the configuration pins no matter what. Combine that with > the stiffness (down to 1 kohm) and you have IOs that can't be > programmed with a resistor to ground and then easily overdriven once > the design is loaded. I think you need about a 330 ohm resistor to > drive it low enough. Then driving it high with an output takes nearly > 10 mA! Some CMOS outputs are only rated for 4 mA drive. yes, a small oversight can mess up a product. In Lattice's case I was surprised they made the 150uA pullups global, on a part that chases 10uA standbys!! - one pin the 'wrong-way', and that's 150uA! -jgArticle: 111498
"Tommy Thorn" <tommy.thorn@gmail.com> wrote in message news:1162583532.646676.89540@h48g2000cwc.googlegroups.com... > > Thanks to OP for the info. I received my kit from Digilent yesterday. > > (What's different about stepping 1?) > > It _is_ very spartan -- it ships with exactly: the board, a power > dongle, and a usb cable. The board runs a little self-test upon power > on, but I'm a bit concerned that the regulator chip gets burning hot, > in fact the area in a 1cm radius looks burned! > > Even though the Digilent page and the schematics claim 32 MiB, it > features a 64 MiB DDR SDRAM, just like the regular Spartan 3E starter > kit. > > My only disappointment is the very minimal documentation and the > complete lack of a pre-cooked constaint file. The pin assignment is > different from the regular Spartan 3E starter kit, so you can't just > reuse the constaints from there, assuming you could locate a comple > description for that. > > I started building my own based on the schematics, but it seems > completely crazy that every user would have to go though this pain. > Even then, what are the IO standards supposed to be? In the > Xil3S500E_Serial_Flash_v81, the sys_clk_in is given as LVCMOS33 where > as most every else it's given as LVTTL? Does it not matter? > > Thanks, > Tommy Dang. I'm happy I didn't just turn my board on with my new design and expect it to work with possibly damaging results. I expected the board to be the exact same board as the 500E Starter Kit. I'm getting the .ucf sent to me now and I'll pass it along to you, Tommy, at your gmail address. It appears the status - even though we've purchased the board - is kind of "pre-release" and we should expect more documentation in the near future. I'm told this board should (at some point) be mostly supported through Xilinx rather than Digilent, Inc.Article: 111499
rickman schrieb: > Will Dean wrote: > >>"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message >>news:454a42f8$1@clear.net.nz... >> >>>yes, but I'm really interested to see how you design with discrete >>>logic, and still get 40% reserve capacity - I know, use a >>>HEF4894, when a HEF4794 would do ! :) >> >>And I was interested in the 'eight or so' chips which fit into the space of >>the TQFP-100... >> >>Will > > > Three dual 4 input muxes (analog switch based), a 4 bit counter, a dual > tri-state buffer, a dual NAND gate and a dual FF. Together with two 8 > bit SPI port relay drivers, they all fit in a 10 x 20 mm area. Up to here, I count only 33 macrocells, probably less. The > smallest CPLD I can easily use is a 128 macrocell part in a 100 pin > TQFP at 16 mm sq package and still requires the two relay drivers plus > a JTAG header. Why not use a 64MC device in CS package? Kolja Sulimma
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