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
Antti Lukats wrote: > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:4172C4C1.7EB97771@yahoo.com... > [snip] > > > > NIOS-1 GPL2 licensing > > > http://www.eecg.toronto.edu/~plavec/utnios.html > > > > > > NIOS-II verilog also exists, but it will not be GPL ;) > > > > I see that you have a benchmark to download. Is there any clock speed > > info on your design? I would be interested in how fast it can run in an > > ACEX EP1K part. How many LEs is it? Does it include the 16 bit > > version? > > Hi Rick, > > the NIOS-GPL includes CPU C-benchmarks, not FPGA benchmarking or statistics > there the NIOS-1 is seems to be a university project - I simply just found > it - haha just enter "NIOS verilog source" into google and that the 3rd hit! > > the design clamis to be 1:1 drop in replacement for Altera NIOS and it looks > that is not 100% clean room implementation, so I guess the GPL license is > actual invalid because of that. > > The NIOS-1 GPL uses altera memprims, and I havent yet checked it with any > synthesis tools. > > The NIOS-II, thats different, its completly clean-room design, uses no > vendor primitives at all. some statistic are in my latest post about the > NIOX core ;) no FPGA tests yet with NIOX (NI*S II compatible) cpu yet. with > no optimization the NIOX looks like 60MHz+ in slow Virtex devices. Is the NIOX core non-public from UT? Or is this another core? -- 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: 74776
Johan Bernspång wrote: > > Chris wrote: > > > >> Chipscope Pro(tm) sure beats using a logic analyzer > > > > > > > > > > Maybe I'll try this out, it looks like it might be worthwhile. > > > > It sure is worthwhile. I have a system which needs approx. 100 hours to > simulate 500 us in ModelSim. Doing the same thing in Chipscope takes 500 > us and gives me the essence of the results. Yes, I'm currently using the > free version of ModelSim XE, but Hey! WOW! I have no idea what is going on in 100 hours. I am simulating about 800 LEs and 5 blocks of memory, plus a test bench and it takes less than a minute per 5 uS of simulation. -- 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: 74777
Jim Granville wrote: > > rickman wrote: > > Antti Lukats wrote: > > > >>the design clamis to be 1:1 drop in replacement for Altera NIOS and it looks > >>that is not 100% clean room implementation, so I guess the GPL license is > >>actual invalid because of that. > >> > >>The NIOS-1 GPL uses altera memprims, and I havent yet checked it with any > >>synthesis tools. > >> > >>The NIOS-II, thats different, its completly clean-room design, uses no > >>vendor primitives at all. some statistic are in my latest post about the > >>NIOX core ;) no FPGA tests yet with NIOX (NI*S II compatible) cpu yet. with > >>no optimization the NIOX looks like 60MHz+ in slow Virtex devices. > > > > > > I know the NIOS-1 was designed to run in the ACEX parts as well as the > > Cyclone and others. Altera did not designed NIOS-II for the ACEX > > parts, I also don't think it comes in a 16 bit version. > > No, but they do show 3 versions, claiming <600 <1,300 <1,800 LEs > > I could not find a size for the JTAG Debug module, as I doubt > they include that in these numbers ? > > > I have a need for a small, fast MCU. I have been designing my own to use with the > > Forth language. > > Interesting, and sounds usefull. > Do you have Size/Speed indications ? I have done a redesign to change some features and have not synthesized it since. Before that it was around 700-800 LEs, IIRC, without optimizing. I expect this is up a bit, but I plan to optimize some parts of the design that don't synthesize well, the muxes mainly. They can map to the cascade chain for best speed and size. I am shooting for 80 MHz if I can improve the muxes and the decode. > Could you take the 600LE NIOS and use the <= 256 user opcode support, > for better Forth support ? 600 LEs is a very small design, but I don't know if it will be that small in an ACEX since the LE structure is a bit different from newer parts. The ACEX parts are basically the same as the even older EP10K family. > > But the software side is a bit of work. The Altera > > site mentions some pretty high speeds for NIOS-1, but when you research > > it the speed doesn't even reach 40 MHz in the ACEX parts. I wondered if > > the alternate version runs any faster. > > > > I think all of these soft CPUs are a bit larger than what I would like > > to see. So for now, I'll stick with what I have. > > Part of this is 'creeping featurism', as well as a general industry > trend to skip 16 bits, plus the design is easier if the data size > matches the PC size. > 24 bits is supported in some DSPs, tho probably does not > map into the Blocks seen in most FPGAs. > > Maybe an 18 bit Opcode and PC would be a better FPGA medium-core ? > Would top out at ~4MBit code store, and a soft CPU optimised to > run from a serial memory would be an interesting direction. You mean 18 bit word size, not opcode, right? -- 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: 74778
I am confused. I thought the OP was looking for 5 volt tolerant chips, no? I am pretty sure the MAX-II is not 5 volt tolerant. Or is it??? If it is, I would like to know more about the intro schedule. When is the LPM2210 planned? "Paul Leventis (at home)" wrote: > > Hi Vax, > > First, I should point out that Altera's mature MAX 7000 family is likely > sufficient and widely available. The MAX 7000S is a 5.0V device with up to > 256 macrocells. The MAX 7000AE is a 3.3V device with up to 512 macrocells. > Both are available in a wide array of cheap, easy-to-use packages. > > The new low-cost Max II family from Altera also meets many of your > requirements. Max II is 3.3V compatible (both power rail voltage and I/O > voltage). The EPM570 device offers 570 LEs, or roughly 440 macrocells. It > is supported by the free Quartus II Web Edition software, available from our > web site. There are three packages: a 100-pin TQFP (with 76 user I/Os), a > 144-pin TQFP (with 116 user I/Os), and a 256-pin FBGA (with 160 user I/Os). > > The downside is that you can't buy the EPM570 today -- only the EPM1270 is > available. But it is shipping in a pin-compatible 144-pin TQFP, so you > could prototype with it and plug in a EPM570 in early 2005 when it is > available. I don't know the unit prices of any of our chips so I can't help > you out there. > > If we get the Web Edition software from www.altera.com, you can try out all > of our CPLD families to see how they do for density & performance. Your > VHDL should work (provided it is generic) in any of our devices. > > > BTW, is it easy to move a CPLD design (VHDL) to FPGA? It has mostly adders > > (5 MHz or lower) and state machines (20MHz). Thanks. If so, would you also > > let me know what FPGA family to look at, with those requirements applied? > > Max II's core fabric is more like an FPGA -- it uses LUT-based Logic > Elements (LEs) instead of AND-OR macrocells. It also features a segmented, > island-style routing architecture instead of the global fabrics found in > older CPLD families. This family is perfect for you needs. > > Generic VHDL should run push-button on Max II, or any other CPLD/FPGA > product from pretty much any vendor. Just change the target device & push > compile! And the speed targets you mention are slow by modern FPGA/CPLD > standards, so they sound doable. > > Good luck, > > Paul Leventis > Altera Corp. -- 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: 74779
"Jon Beniston" <jon@beniston.com> wrote in message news:e87b9ce8.0410180542.cf7be60@posting.google.com... > "Antti Lukats" <antti@case2000.com> wrote in message news:<ckrbh1$kn7$04$1@news.t-online.com>... > > > Netlists, Documentation and Development tools can be downloaded from > > > http://www.niktech.com. > > > > 1) are you going to release the HDL sources? > > Similarly to you Antti, are you going to be releasing the HDL source for NIOX? > > Cheers, > Jon Hi Jon, lets put it that way, NIOX sources are obtainable ;) AnttiArticle: 74780
gabor@alacron.com (Gabor Szakacs) wrote in message news:<8a436ba2.0410181001.2f80854a@posting.google.com>... > If you only need two output values you really want a single > bit random function which returns 0 or 1. > Then use that bit to select -5 or +5 something like: > reg rval; > integer seed; > integer port; > > forever begin > seed = 1; > rval = $random (seed); > port = rval ? +5 : -5; > . . . > end The approach to selecting between two values is good. However, if you keep resetting seed to 1 every time before you call $random, you will get the same (nonrandom) result every time too.Article: 74781
rickman wrote: <snip> >>Could you take the 600LE NIOS and use the <= 256 user opcode support, >>for better Forth support ? > > > 600 LEs is a very small design, but I don't know if it will be that > small in an ACEX since the LE structure is a bit different from newer > parts. The ACEX parts are basically the same as the even older EP10K > family. Yes, I guess if it was halfway decent in an older device, Altera would have released that - you can be sure they compiled it, to see :) >>>But the software side is a bit of work. The Altera >>>site mentions some pretty high speeds for NIOS-1, but when you research >>>it the speed doesn't even reach 40 MHz in the ACEX parts. I wondered if >>>the alternate version runs any faster. >>> >>>I think all of these soft CPUs are a bit larger than what I would like >>>to see. So for now, I'll stick with what I have. >> >> Part of this is 'creeping featurism', as well as a general industry >>trend to skip 16 bits, plus the design is easier if the data size >>matches the PC size. >> 24 bits is supported in some DSPs, tho probably does not >>map into the Blocks seen in most FPGAs. >> >>Maybe an 18 bit Opcode and PC would be a better FPGA medium-core ? >>Would top out at ~4MBit code store, and a soft CPU optimised to >>run from a serial memory would be an interesting direction. > > > You mean 18 bit word size, not opcode, right? Both, as you tend to naturally make the opcode the same size as the word size. 18 bits allows you to do more with the opcodes, but still fit into the FPGA memory tiles, and some external memory is also x18. It also extends the memory reach, so moves the code/data ceiling further up. -jgArticle: 74782
Jim Granville wrote: > > rickman wrote: > <snip> > >>Could you take the 600LE NIOS and use the <= 256 user opcode support, > >>for better Forth support ? > > > > > > 600 LEs is a very small design, but I don't know if it will be that > > small in an ACEX since the LE structure is a bit different from newer > > parts. The ACEX parts are basically the same as the even older EP10K > > family. > > Yes, I guess if it was halfway decent in an older device, Altera would > have released that - you can be sure they compiled it, to see :) Except that to get so small and fast, these designs have to match the hardware pretty closely. Since the ACEX parts are a different design and I expect much of the NIOS-II uses instantiated logic it would be more work to even fit the design to the part regardless of the resulting speed or size. Even if it didn't run well, if it were not much work, I expect they would release it. My guess is the main difference in the NIOS-I and -II is that the -II takes advantage of the newer features in the newer chips. -- 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: 74783
> I completely fail to understand what MANIK brings to the party.
An excellent question ; at the risk of staring a flame war I will say
"code size". Now, does "code size" matter ? It depends on a lot of
factors, but given the small amounts of BLOCKRAMs available
on a FPGA, it would matter in "most" cases, especially if the
code size saving is substantial.
I have done a comparison with MIPS and to eliminate different libraries
I have compared the sizes of the individual object files. Note the MANIK
tool chain merges text and data section into text section. In both cases
the sizes of the uninitialized global variables are not listed (size
command does not display it).
-----------------------------------------------------------------------
Dhrystone (complied with -O2)
MIPS
text data bss dec hex filename
1363 26 0 1389 56d dhry21a.o
620 0 0 620 26c dhry21b.o
MANIK
text data bss dec hex filename
919 0 0 919 397 dhry21a.o
416 0 0 416 1a0 dhry21b.o
While code size is the strongest suite of MANIK; it does have other
goodies; ability to execute multiple instructions simultaneously;
power down mode, built in timer; are just a few of them.
Following is a file by file comparison of a benchmark (099.go) from
the SPEC95 suite (Does not have any uninitialzed globals) . How much
will you save ? Give it a try with the MANIK toolchain .....
-------------------------------------------------------------------------
Files of 099.go (from SPEC95 benchmark)
-------------------------------------------------------------------------
MIPS
text data bss dec hex filename
3170 863 0 4033 fc1 g2.o
7824 0 0 7824 1e90 g22.o
69236 880 0 70116 111e4 g23.o
64318 1440 0 65758 100de g25.o
3448 0 0 3448 d78 g26.o
6804 8 0 6812 1a9c g27a.o
2596 224 0 2820 b04 g27b.o
11976 0 0 11976 2ec8 g28.o
27616 0 0 27616 6be0 g29.o
19600 1100 0 20700 50dc g2eye.o
0 49784 0 49784 c278 g2jlib2.o
7488 12 0 7500 1d4c g2jos.o
2760 0 0 2760 ac8 g2list.o
6803 5260 0 12063 2f1f g2reas.o
12372 0 0 12372 3054 g2s2.o
4730 4 0 4734 127e g2s3.o
29600 14484 0 44084 ac34 g2shp.o
MANIK
text data bss dec hex filename
3258 0 0 3258 cba g2.o
5232 0 0 5232 1470 g22.o
46320 0 0 46320 b4f0 g23.o
42522 0 0 42522 a61a g25.o
2220 0 0 2220 8ac g26.o
4480 0 0 4480 1180 g27a.o
1776 0 0 1776 6f0 g27b.o
7716 0 0 7716 1e24 g28.o
17784 0 0 17784 4578 g29.o
13660 0 0 13660 355c g2eye.o
49784 0 0 49784 c278 g2jlib2.o
4860 0 0 4860 12fc g2jos.o
1928 0 0 1928 788 g2list.o
12064 0 0 12064 2f20 g2reas.o
8268 0 0 8268 204c g2s2.o
3874 0 0 3874 f22 g2s3.o
33712 0 0 33712 83b0 g2shp.o
[
--
-----------------------------------------------------------------
http://www.niktech.com
Specializing in FPGA based Processors
-----------------------------------------------------------------
Article: 74784Tony K wrote: [snip] > is not selected). Now I have created an arp entry in the table for my > board MAC. ex. arp -s 192.168.1.0 00-00-01-02-03-04. I can verify the > entry its there. Now when I Ping my board from pc the packet is never > received. Any help will greatly appreciated. I been working on this > for couple of days. > > > thanks. > > TONY If you don't do that already you might run a network sniffer, like Ethereal http://www.ethereal.com/, to trace what is going on on the network. Then you will see whether the packet actually leaves your PC. The IP address that you posted is actually a network address. You might try to use 192.168.1.1. BTW, what is IP address and subnet mask of the PC? GuenterArticle: 74785
>Our SSO rules assume you have dedicated planes for Vccint, Vcco. If you >do not have both a power and a ground plane for each of these supplies, >the SSO numbers must be reduced. This also goes for simultaneously >switching CLBs, and not just IOs. We assume a power and ground plane >(yes that would be four layers just for power) for low inductance on the >Vccint/Vcco. That seems reasonable, but it's awful short on specifics. How big does the plane have to be? Are you assuming power/gnd pairs? If so, what spacing between the pairs? Which plane/pair needs to be closest to the chip? Is there a procedure for computing the SSO rules given non-optimal power planes? Wise-ass mode would be: What page of the data sheet describes the details? Let's go at it from the other direction. What are the chances of making a solid PCI card on a 4 layer board? Assume a TQFP-208 package and assume that the PCI side is the major SSO problem and that the routing on the non-PCI signals is easy. I haven't done it, but I think you can get a reasonable layout in 4 layers with a TQFP package. I'm assuming that the routing to the signal pins from the rest of the design is easy. (That's "reasonable" to my imagination/eyeball. Reality might be totally different.) The idea is that the top/bottom layers under the chip are not needed for routing so you can fill them with copper to get a tiny plane. It's probably not big enough to do much good, as a plane, but it will be a solid connection for all the appropriate power/gnd pins and bypass caps. It would be interesting to see how good that chunk of plane approach is compared to placing bypass caps right next to each pair of power/ground pins (with tight routing and fat traces). I've got a cheap modem PCI card handy. Looks like it's only 2 layers. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 74786
rickman wrote: > WOW! I have no idea what is going on in 100 hours. I am simulating > about 800 LEs and 5 blocks of memory, plus a test bench and it takes > less than a minute per 5 uS of simulation. =20 >=20 Well, it's a quite large design sampling the input at 200 MHz (from an=20 ADC), CIC filters, LP FIRs, CORDIC, BP FIRs etc. I.e. lots of=20 calculations for my poor ModelSim. Earlier in the design cycle I've been trying to avoid simulations due to = the complexity of the system. But I gave it a try anyway since I was=20 occupied with some other stuff for a few days... --=20 ----------------------------------------------- Johan Bernsp=E5ng, xjohbex@xfoix.se Research engineer, embedded systems Totalf=F6rsvarets forskningsinstitut Swedish Defence Research Agency Please remove the x's in the email address if replying to me personally. -----------------------------------------------Article: 74787
>Yes we have plans of porting Operating Systems to the processor; >uC/OS and uClinux seem to be good choices for a CPU like >MANIK. Sciopta (the company I work for) should be easyly ported. (If code-size and speed matters :-) A reason why I downloaded the GCC :-) -- 42Bastian Do not email to bastian42@yahoo.com, it's a spam-only account :-) Use <same-name>@epost.de instead !Article: 74788
tails_naf@yahoo.com (Tails) wrote in message news:<987636ca.0410171546.15d5b86b@posting.google.com>... > So Antti, > Can you answer the burning question: > Does a Spartan-3 Nios-II beat a > cyclone Microblaze in performance/area? > How do the two compare? Well, I have been working on my own CPU. It runs at 88MHz in a Spartan 3 and 115MHz in a Cyclone II (fastest speed grade for both devices / post-layout timing). Given this is pretty much the same frequency (maybe a little faster :) ) as is achieved by MicroBlaze and NIOS II, I would say that they are very likely to achieve similar results if implemented in their competitors devices. This isn't really too much of a surprise given that both processors are quite similar. Cheers, JonArticle: 74789
>> Fire your synthesize tool and see how much resources you'd really need! Yes, this is my point, Both structures have different resources, when write your code; your code stile make the difference. Walter. "Arash Salarian" <arash.salarian@epfl.ch> a écrit dans le message de news:417397f6$1@epflnews.epfl.ch... > "Walter Gallegos" <walter@chasque.apc.org> wrote in message > news:10n2h60q87tig87@news.supernews.com... > > The answare is > > > > 1 slice into a Spartan 3 > > 16 LE into a MAX-II > > > > Can you compare this architectures as 1 Slice = 2 LE's ? > > > > I agree that there some areas that you can't simply compare the two > architectures. For example, I had an old design with an Altera 10K series > that used a fully async RAM block. Now, move it to a Spartan 3 architecture > and you see that you should use the whole chip just to make that block of > async RAM! > However, it is perfectly understandable that a user might need to compare > different available options and to do this, he/she would need to have rough > estimates to compare a Xilinx device to that of Altera. For example, > recently I had this interesting offer for a an FPGA prototype board with > the same price of $99 for an Altern EP1C12 or a Xilinx XC3S400. I would like > to use a prototype board for very different designs so I had to compare > between the two chips. As I program in VHDL and use synthesize tools, I > don't really care for any specific architecture (unless something like your > example or my example above happens) and the thing that matters in cases > like that is you only look for the BIGGER FPGA. To do it, you need to > compare and to compare you can only use rough estimates. > Personally, I find the simple equation of 1 Slice = 2 LE a very good rough > estimate and for many designs it gives you a good answer. You have a very > specific design and need a very good answer? Fire your synthesize tool and > see how much resources you'd really need! > >Article: 74790
Hi @ all, is it possible to feed the input of a second PLL (Cyclone EP1C12) with an output clock (for example c0) of the first PLL ? I mean the two PLLs are positioned in opposed banks. Or can PLLs only be fed with external clocks on dedicated clock pins? Thank you for your help. Rgds AndréArticle: 74791
Hello together, has anyone experience with tristates in SPARTAN3-fpgas? If we implement a schematic-oriented structure we won't get any error-messages but only warnings and the design will be compiled fine. But it seems that all our tristate outputs are driven permanently (which is very bad!). Hints are very appreciated! Thanks, Thomas.Article: 74792
Hallo, I'm a bit unsatisfied with the "xst 5.2"-design flow for xilinx. For example, when targeting for SpartanII, "map" isn't able to implement the ROM64x1 primitive, although the device has F5mux and F6mux, so one could code a ROM64X1 äquivalent macro by hand. A more important example is the SRL16 and RAM16X1S primitives. Again, it's "map" reporting, that SRL16 + RAM16X1S aren't supported on F-LUT of a slice on SpartanII, although the SpartanII Data Sheet unmistakeable states: | In addition to operating as a function generator, each LUT can | provide a 16 x 1-bit synchronous RAM. [...] | The Spartan-II LUT can also provide a 16-bit shift register | that is ideal for capturing high-speed or burst-mode data. I plan to design using mostly self-made tools, and upto now, my plan was to feed completly mapped (but only relativly placed and only partially routed) CLB-lists through HDL into the xst-flow. Any suggestions on alternative ways to do this? Furthermore, I'm still searching for exact documentation (hopefully in machine-readable form) of xilinx-device resources. What about these ".spd",".nph",".pkg",".dll",".acd",".usg",".bsd",".lib"-files? Gruss Jan BrunsArticle: 74793
I have implemented the read/write operation, but I still cant get the bar assignment:( there is some problem: I can see my card under windows (but bar0 not assigned), but I can not see the card by BIOS. ( from the table on the screen after POST before boot OS) what's the problem?? BTW: I dont implement the interrupt pin.Article: 74794
Thomas Bartzick a écrit: > Hello together, > > has anyone experience with tristates in SPARTAN3-fpgas? > If we implement a schematic-oriented structure we won't get any > error-messages but only warnings and the design will be compiled fine. > But it seems that all our tristate outputs are driven permanently > (which is very bad!). I have just finished a VHDL PCI design in a Spartan3 and so far it works (tests are still in progress but tristate outputs are OK) -- ____ _ __ ___ | _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le - | | | | | (_| |_| | Invalid return address: remove the - |_| |_|_|\__|\___/Article: 74795
i was just looking at virtex and stratix architectures. i observed that direction of carry chain is bottom to top and direction of shift chain is top to bottom for virtex devices, whereas it appears that both are in the same direction in stratix. Just wondering if it is just a coincidence or is this intentional?Article: 74796
Hal, For specifics, please read: http://www.support.xilinx.com/products/design_resources/highspeed_design/resource/si_power.htm SSO guidelines are on page 23 of: http://direct.xilinx.com/bvdocs/publications/ds099-3.pdf Austin Hal Murray wrote: >>Our SSO rules assume you have dedicated planes for Vccint, Vcco. If you >>do not have both a power and a ground plane for each of these supplies, >>the SSO numbers must be reduced. This also goes for simultaneously >>switching CLBs, and not just IOs. We assume a power and ground plane >>(yes that would be four layers just for power) for low inductance on the >>Vccint/Vcco. > > > That seems reasonable, but it's awful short on specifics. > > How big does the plane have to be? Are you assuming power/gnd pairs? > If so, what spacing between the pairs? Which plane/pair needs > to be closest to the chip? > > Is there a procedure for computing the SSO rules given non-optimal > power planes? > > Wise-ass mode would be: > What page of the data sheet describes the details? > > > Let's go at it from the other direction. What are the chances of > making a solid PCI card on a 4 layer board? Assume a TQFP-208 > package and assume that the PCI side is the major SSO problem > and that the routing on the non-PCI signals is easy. > > > I haven't done it, but I think you can get a reasonable layout > in 4 layers with a TQFP package. I'm assuming that the routing > to the signal pins from the rest of the design is easy. > (That's "reasonable" to my imagination/eyeball. Reality might > be totally different.) > > The idea is that the top/bottom layers under the chip are not > needed for routing so you can fill them with copper to get > a tiny plane. It's probably not big enough to do much good, > as a plane, but it will be a solid connection for all the > appropriate power/gnd pins and bypass caps. > > It would be interesting to see how good that chunk of plane > approach is compared to placing bypass caps right next to each > pair of power/ground pins (with tight routing and fat traces). > > > I've got a cheap modem PCI card handy. Looks like it's only > 2 layers. >Article: 74797
"Hal Murray" <hmurray@suespammers.org> wrote in message news:t7-dnUVydsUKXOncRVn-oQ@megapath.net... > That seems reasonable, but it's awful short on specifics. > > How big does the plane have to be? Are you assuming power/gnd pairs? > If so, what spacing between the pairs? Which plane/pair needs > to be closest to the chip? > > Is there a procedure for computing the SSO rules given non-optimal > power planes? > > Wise-ass mode would be: > What page of the data sheet describes the details? > > > Let's go at it from the other direction. What are the chances of > making a solid PCI card on a 4 layer board? Assume a TQFP-208 > package and assume that the PCI side is the major SSO problem > and that the routing on the non-PCI signals is easy. > > > I haven't done it, but I think you can get a reasonable layout > in 4 layers with a TQFP package. I'm assuming that the routing > to the signal pins from the rest of the design is easy. > (That's "reasonable" to my imagination/eyeball. Reality might > be totally different.) > > The idea is that the top/bottom layers under the chip are not > needed for routing so you can fill them with copper to get > a tiny plane. It's probably not big enough to do much good, > as a plane, but it will be a solid connection for all the > appropriate power/gnd pins and bypass caps. > > It would be interesting to see how good that chunk of plane > approach is compared to placing bypass caps right next to each > pair of power/ground pins (with tight routing and fat traces). > > > I've got a cheap modem PCI card handy. Looks like it's only > 2 layers. > Hal, For this PCI card, I think the I/O will be your toughest problem. 32+ long traces at 33MHz. So, I'd consider this. Assume four layers, 1, 2, 3 & 4. FPGA mounted on layer 1. First, make layer 2 a ground plane. Underneath the FPGA on layer 1, fill the area with copper and connect to all the Vcco pins. Layer 3 under the FPGA should be copper flooded for Vccint. You now put a chunky C shape around the Vccint flood on Layer 3 to route Vccaux. Via Vccint, Vccaux and Ground to each and every required pin on the FPGA, but keep the vias inside the square of FPGA pins, to avoid hindering routing your I/O signals outwards on layer 1. Vcco vias can connect to anywhere on your layer 1 mini-plane under the FPGA. If you have more than one Vcco, you can divide up this mini plane, but try to group banks that share a Vcco together. On layer 4 under the FPGA, pack with bypass caps for Vcco and Vccint. (Check XAPP623 for good advice on layout for bypass caps.) You need at least one via for the power end of the cap, more is better, don't share vias between caps. Flood the rest of this bit of layer 4 with ground for the bypass caps, and use many vias to connect this layer 4 ground flood to Layer 2, your ground plane. Now, route your signals out on layer 1. Cram them together so that you can fit extra bypass caps onto layer 1, for each of Vccint, Vcco, Vccaux. As for bypass caps, use 0805s on layer 4. Use 0402s on layer 1. Via inductance is around 1.2nH, double the capacitor inductance, so don't worry about high frequencies on the bottom layer. In fact for a PQ208 the lead inductance is probably around 10nH, so don't worry about all that 'spread of capacitance values' crap, big capacitance is beautiful here! Try it, you never know, you might be one of Austin's lucky ones! ;-) Cheers, Syms.Article: 74798
Hal Murray wrote: >>Our SSO rules assume you have dedicated planes for Vccint, Vcco. If you >>do not have both a power and a ground plane for each of these supplies, >>the SSO numbers must be reduced. This also goes for simultaneously >>switching CLBs, and not just IOs. We assume a power and ground plane >>(yes that would be four layers just for power) for low inductance on the >>Vccint/Vcco. > That seems reasonable, but it's awful short on specifics. > How big does the plane have to be? Are you assuming power/gnd pairs? > If so, what spacing between the pairs? Which plane/pair needs > to be closest to the chip? Inductance should also go down with the thickness of the copper, though at some point you run into the skin effect. Thicker copper might be cheaper than more layers. -- glenArticle: 74799
"Johan Bernspång" <xjohbex@xfoix.se> wrote in message news:cl2g6r$fn7$1@mercur.foi.se... > Well, it's a quite large design sampling the input at 200 MHz (from an > ADC), CIC filters, LP FIRs, CORDIC, BP FIRs etc. I.e. lots of > calculations for my poor ModelSim. Of course, you simulated each of these blocks separately to verify they worked? ;-) Cheers, Syms.
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