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
Austin Lesea schrieb: > jaxato, > > I am not involved in that battle, as Peter is fighting it. > > He and I both agree that not having an on line store in this day and age > is unacceptable. > > As soon as Peter returns from Europe, I am sure he will let us know how > it is progressing (or not). > > Please send all your request to Peter directly (if you haven't already). > Each email helps just a little bit. > > Austin Austin & Peter, it should be fairly simple to make the point for the online shop - just ask some one from the management to hire an survey where a few different entities around the world would try place orders and get confirmation and parts and test order on * Spartan3E * Virtex-4 * Virtex-5 the test entitities could include 1) a student from Pakistan 2) a small company in Bulgaria 3) some hobby person in UK or Germany 4) an reputable company in New Zealand 5) ? the results of the test order survey should be enough to open the online store really quickly. AnttiArticle: 107501
neha.karanjkar@gmail.com schrieb: > Hi all. > I'm an undergrad student doing a year long project on designing an 8051 > variant for FPGA. > We're required to decide upon the specifications, by targeting any > particular application. > I'd be really thankful for any suggestions for the applications.... > Could someone guide me to sites that offer a comparison, & > applications of available 8051 cores? > > thanx in advance there are many many many free and commercial 8051 derivates. spending a year to make another clone really doesnt make sense unless there is something around the 8051 that makes the whole SoC different from the current offerings. AnttiArticle: 107502
I have one last thing to add to this thread, this caused me a lot of trouble... Let me quote the PPC405 block reference guide: "For devices with more than one PPC405 core, users must connect the JTAG logic for ALL of the PPC405 cores on the device when using this connection style, even if some are not otherwise used". I might add that if you don't do that, the end result is "programming failed" in iMPACT but without any error to point to the above cause (very hard to troubleshoot). Actually the UC2 reference designs for "Dual PPC405" do everything correctly. Contrary to what I thought, "Dual PPC405" is not a design using both PPC, actually it's a design using only one PPC and wiring the second one as "idle". So you MUST use this reference design if you have two PPC in your chip, even if you plan on using just one. I found an old thread with this solution to a "program failed" problem someone else was having (solution given by Peter Ryser, again): http://tinyurl.com/rqkgz PatrickArticle: 107503
"rickman" <gnuarm@gmail.com> wrote in message news:1156861074.825726.84320@h48g2000cwc.googlegroups.com... > I would love to see some data to support that statement about the lower > inductance. I don't have Ritchey's book handy, but I seem to recall > that moving the vias from the end of the pads to the side was only a > small delta in total inductance (significantly smaller loop area). I > expect that moving them to the center would be another small delta. > This has to be considered in the context of both the inductance of the > device itself as well as the result on the impedance of the board. > > I think you will find that small changes in inductance do not have a > major effect on the utility of the caps. If you use multiple caps with > mutiple values you can get a low impedance over a wide bandwidth with a > minimum number of caps. I have no doubt that using via in pad will > help to raise the resonant frequencies, but I think you will find that > if you do all the other things right it will not make much difference > in the end. Won't any higher inductance result in the same above-SRF slope? That is, given the total inductance, it won't matter what the capacitance is once above an ohm in the impedance vs freq plot. I've seen good information on Cadence tools based on Sun Microsystems work that tracks what you've described with Ritchey. A recent Howard Johnson / Xilinx talk also covered many of these items well without contradiction. In each case, the lowest inductance achievable was always the goal. The small deltas may be small in nanoHenrys but are probably a significant percentage. Same-side vias are better for a cap than end vias. Vias in pad are better. Partial vias in pad are best. That's the understanding I got. A distribution of capacitance can give a superb, flat impedance over a wide frequency range. Resonance is a problem for low ESR caps too far apart in frequency such that they cancel each other out with an LC resonance between the SRFs of the two values. Vias in pads provide better performance.Article: 107504
"Nial Stewart" <nial@nialstewartdevelopments.co.uk> schrieb im Newsbeitrag news:4lj0v7F261tbU1@individual.net... > "Nevo" <nevo_n@hotmail.com> wrote in message > news:0NjIg.1843$XD1.927@trnddc01... >> I'm designing a Cyclone device and am having problems with one pin. >> >> I want to use the configuration pin ASDO as an I/O pin after my device >> finishes active serial configuration. I assigned my I/O to that pin but >> the fitter barks at me that it "Can't place node ~ASDO~ in location 37 >> because location already occupied by Q[0]" >> I went to Assignments... Device... Device & Pin Options... Dual-Purpose >> Pins, but the setting for ASDO is greyed out. >> How do I tell Quartus to let me use that pin as an I/O pin after AS >> configuration? > > > It's not explicitly defined on that config page but looking at it > I'd say that if you're using active serial config then ADS0 isn't > later available as a user IO pin. > > Probably worth confirming with an Altera FAE. > > > Nial its doable, but you need to use ASMI prmitive AnttiArticle: 107505
Antti wrote: > neha.karanjkar@gmail.com schrieb: > > >>Hi all. >>I'm an undergrad student doing a year long project on designing an 8051 >>variant for FPGA. >> We're required to decide upon the specifications, by targeting any >>particular application. >>I'd be really thankful for any suggestions for the applications.... >> Could someone guide me to sites that offer a comparison, & >>applications of available 8051 cores? >> >>thanx in advance > > > there are many many many free and commercial 8051 derivates. spending a > year to make another clone really doesnt make sense unless there is > something around the 8051 that makes the whole SoC different from the > current offerings. > > Antti > It's a _class project_ for crying out loud! The real point is to start from something that's pretty fully specified, then make it work in the real world. Applicability has little to do with it. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 107506
Jim, We have certainly thought about it. Byte Craft has done quite a bit of instruction design work on embedded commercial processors. Internally for every C compiler we create an instruction set simulator with a lot of performance instrumentation. I expect the next round of processors will move towards multiple processor solutions to applications. Compilers and other HLL tools will be focused on application work division. w.. Jim Granville wrote: > Walter Banks wrote: > > > > > Interrupts can be removed at extremely low cost to applications. Both the > > Microchip PIC12 and Freescale RS08 do not have interrupts. In the > > RS08 C compiler we developed some software IP to where possible > > go into a power down mode and launch execution threads that compiled as > > execution to completion. > > > > The threads are typically short and a as a side effect run to completion > > makes local re-use easy > > > > C compilers implemented for small processors work well with out either > > a data or subroutine return stack. Two of the processors we have written > > compilers for in the last couple years both used an assessable return > > register. Flow control analysis in the compiler make nested subroutines > > user transparent. > > > > The instruction set reduction in the RS08 from the S08 parent had a > > 4-6% impact on application performance. > > > > Walter.. > > Hi Walter, > Have you ever thought about doing a Compiler+FPGA_CPU (+Sim+Debug?) > bundle ? > > -jgArticle: 107507
neha.karanjkar@gmail.com wrote: > Hi all. > I'm an undergrad student doing a year long project on designing an 8051 > variant for FPGA. > We're required to decide upon the specifications, by targeting any > particular application. > I'd be really thankful for any suggestions for the applications.... > Could someone guide me to sites that offer a comparison, & > applications of available 8051 cores? > > thanx in advance > Just about anything that you can think of that might have a small microprocessor in it has been built with an 8051. * Clocks * Electronic flush toilets * Room thermostats * Temperature controllers for processing illegal drugs * Temperature controllers for processing legal drugs * Temperature controllers for labs determining whether mysterious white powders are illegal drugs * Microwave controllers * Photosynthesis activity meters (I maintained one of those) * Leaf area meters (ditto) * Motion controllers * Burglar alarm systems * Video games * etc. * etc. * etc. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 107508
Eli Bendersky wrote:
> Is all code using variables always synthesizable, and can you tell by a
> single look how many clock cycles the update of all values take ?
The variables are updated every clock
but that "update" may be to keep the
same value.
> I'd
> really appreciate a simple example or two.
The advantages of a variable logic description
*increase* with complexity, so a persuasive
yet simple example is a challenge.
My favorite simple example is the
"clock enabled counters" source here:
http://home.comcast.net/~mike_treseler/
The focus is on updating values for simulation
rather than recipes for gates and flops.
The procedure "update_regs"
only describes value updates
required for the slow, medium and fast counts.
Note that I read carry bits and immediately clear
them without worrying about what that means in gates or flops.
Note in the RTL schematic view (object) that synthesis does
just fine working out how the carries and enables
work and where registers are not needed.
Also note that a process-per-block description using this view
would be more complicated than the example source.
-- Mike Treseler
Article: 107509We have been encouraged to spend some of our remaining training budget by taking a week-long seminar in September. I am looking for something concerning FPGA design, wireless networks, or just general engineering. My preference would be somewhere in southern California, but other places may be negotiable. Any suggestions?Article: 107510
mikegurche@yahoo.com wrote: > In synthesis, the problem is normally the abuse of sequential > statements, rather than the use of variable. I have seen people trying > to convert C segment into a VHDL process (you can have variables, for > loop, while loop, if, case, and even break inside a process) and > expecting synthesis software to figure out everything. Personally I think most problems in using HDLs in this way come not directly from the way signals or variables are used, but rather from the use of an HDL to describe the solution in an abstract way. I nearly always design in terms of registers and "clouds" for the logic. I get a feel for how large the design is and if I need to optimize at this block diagram level. I can even get an idea of how complex the logic part is by looking at the equations that describe it. Then I use an HDL to "describe" the hardware rather than describing the functionality and letting the tool decide what hardware to invoke. If I know I want a register, I add the code that will infer a register. If I need a certain logic, I can include those equations in the register process or I can use combinatorial descriptions separately. I never start writing the HDL before I have a clear understanding of what the hardware should look like. To me the HDL is just the lowest level description of a sucessive decomposition of the design. The HDL is never used to "program" a solution. This seldom results in the types of problems you are discussing. Just for the record, I do use integer variables for memory or other sequential logic like counters. Memories simulate much faster when coded with integer variables. This is both because of the integer and the variable, IIRC.Article: 107511
Richard Henry wrote: > We have been encouraged to spend some of our remaining training budget > by taking a week-long seminar in September. I am looking for something > concerning FPGA design, wireless networks, or just general engineering. > My preference would be somewhere in southern California, but other > places may be negotiable. > > Any suggestions? We can book a 7 days cruise from LA to Mexico and do hand-on training/experiments with FPGA. How many are coming?Article: 107512
rickman wrote: > mikegurche@yahoo.com wrote: > > In synthesis, the problem is normally the abuse of sequential > > statements, rather than the use of variable. I have seen people trying > > to convert C segment into a VHDL process (you can have variables, for > > loop, while loop, if, case, and even break inside a process) and > > expecting synthesis software to figure out everything. > > Personally I think most problems in using HDLs in this way come not > directly from the way signals or variables are used, but rather from > the use of an HDL to describe the solution in an abstract way. I > nearly always design in terms of registers and "clouds" for the logic. > I get a feel for how large the design is and if I need to optimize at > this block diagram level. I can even get an idea of how complex the > logic part is by looking at the equations that describe it. Then I use > an HDL to "describe" the hardware rather than describing the > functionality and letting the tool decide what hardware to invoke. > I agreed with you completely. What I am trying to say is that variable may not be synthesizable if you write the code with a "C mentality." Mike G.Article: 107513
rickman wrote: > mikegurche@yahoo.com wrote: > > In synthesis, the problem is normally the abuse of sequential > > statements, rather than the use of variable. I have seen people trying > > to convert C segment into a VHDL process (you can have variables, for > > loop, while loop, if, case, and even break inside a process) and > > expecting synthesis software to figure out everything. > > Personally I think most problems in using HDLs in this way come not > directly from the way signals or variables are used, but rather from > the use of an HDL to describe the solution in an abstract way. I > nearly always design in terms of registers and "clouds" for the logic. > I get a feel for how large the design is and if I need to optimize at > this block diagram level. I can even get an idea of how complex the > logic part is by looking at the equations that describe it. Then I use > an HDL to "describe" the hardware rather than describing the > functionality and letting the tool decide what hardware to invoke. > I agreed with you completely. What I am trying to say is that variable may not be synthesizable if you write the code with a "C mentality." Mike G.Article: 107514
I go to www.xilinx.com, and click on "Virtex 4 FPGA" (on the left under "Products") This brings up the URL http://www.xilinx.com/products/silicon_solutions/fpgas/virtex/virtex4/index.htm At this URL, on the right, under "Related Information", there is a link named "Virtex-4 package files" The actual URL this link points to is http://www.xilinx.com/products/virtex4/virtex-4-pkgs.htm I click on it and wind up back at exactly the same page. So I tried downloading and playing with the .bsd files, but they are missing a lot of info (like global clock stuff). Where can I find the ASCII package files? Thanks, PatArticle: 107515
<pmaupin@gmail.com> wrote in message news:1156878292.284453.40820@h48g2000cwc.googlegroups.com... > > Where can I find the ASCII package files? Try this link: http://www.xilinx.com/products/silicon_solutions/fpgas/virtex/virtex4/resources/virtex-4-pkgs.htm To get there from the page where you started you should have chosen All Virtex-4 Resources and then Package Files under the Documentation... /MikhailArticle: 107516
John_H wrote: > "rickman" <gnuarm@gmail.com> wrote in message > Won't any higher inductance result in the same above-SRF slope? That is, > given the total inductance, it won't matter what the capacitance is once > above an ohm in the impedance vs freq plot. I'm not sure what you are asking. A different capacitance will not change the inductive part of the impedance curve and a different inductance will not change the capacitive part of the curve. What changes in both cases is the SRF. So you put a few 0.1 uF caps on the board and a number more of 0.01 uF caps and even more of the 0.001 uF caps. Each capacitance value needs to have sufficient quantity to bring the impedance near the SRF low enough to be effective. Then the capacitive effect of the smaller caps keep the overall impedance low in spite of the larger caps being inductive. Finally the impedance of the ground planes keep the impedance low for the highest frequency. Doing a simulation is always a good thing to be able to see how the parallel resonances affect the impedance. > I've seen good information on Cadence tools based on Sun Microsystems work > that tracks what you've described with Ritchey. A recent Howard Johnson / > Xilinx talk also covered many of these items well without contradiction. The contradiction part I don't agree with. Many still argue that the distance between the IC and the cap is critical and some still say quantity is more important than variety of SRF. In one of these threads there was a link to a post by HJ. There were some things in the HJ post that were not supported by any sort of measurement or even simulation. I don't recall the details. > In each case, the lowest inductance achievable was always the goal. The > small deltas may be small in nanoHenrys but are probably a significant > percentage. Not inductance, impedance. I don't care about inductance if I can keep the impedance low over the frequency range that matters to my design. The small deltas in inductance only move the SRF, they don't have a large impact on the impedance after you mix the capacitor values. > Same-side vias are better for a cap than end vias. Vias in pad are better. > Partial vias in pad are best. That's the understanding I got. Yes, but none are really bad and it is a cost (or design/fab effort) vs. benifit. Same-side vias are pretty much free in all respects. Via in pad has some design effort if you have not done it before and some PCB vendors don't like to make them (but that varies). Partial vias (I assume you mean blind) are very expensive and clearly not worth the effort unless you are doing some really high freq work. Even then, I don't think they are needed for making the power delivery work well. Blind vias might be warranted in the signal path when you get near 10 GHz or so, but this is what I am remembering from the class, not anything I have seen myself. Ritchey was pretty impressive because he always uses the simplest methods and verifies that it will work before he builds the actual board. I don't beleive he said he has ever used vias in pads even with near 5 GHz boards. > A distribution of capacitance can give a superb, flat impedance over a wide > frequency range. Resonance is a problem for low ESR caps too far apart in > frequency such that they cancel each other out with an LC resonance between > the SRFs of the two values. Vias in pads provide better performance. How much better? If your design is so critical that you need to put the vias in the cap pads, then likely you need to do a careful simulation of the power distribution to see exactly what you have rather than to rely on general guidelines that may or may not allow a given design to work.Article: 107517
John_H wrote: > "rickman" <gnuarm@gmail.com> wrote in message > Won't any higher inductance result in the same above-SRF slope? That is, > given the total inductance, it won't matter what the capacitance is once > above an ohm in the impedance vs freq plot. I'm not sure what you are asking. A different capacitance will not change the inductive part of the impedance curve and a different inductance will not change the capacitive part of the curve. What changes in both cases is the SRF. So you put a few 0.1 uF caps on the board and a number more of 0.01 uF caps and even more of the 0.001 uF caps. Each capacitance value needs to have sufficient quantity to bring the impedance near the SRF low enough to be effective. Then the capacitive effect of the smaller caps keep the overall impedance low in spite of the larger caps being inductive. Finally the impedance of the ground planes keep the impedance low for the highest frequency. Doing a simulation is always a good thing to be able to see how the parallel resonances affect the impedance. > I've seen good information on Cadence tools based on Sun Microsystems work > that tracks what you've described with Ritchey. A recent Howard Johnson / > Xilinx talk also covered many of these items well without contradiction. The contradiction part I don't agree with. Many still argue that the distance between the IC and the cap is critical and some still say quantity is more important than variety of SRF. In one of these threads there was a link to a post by HJ. There were some things in the HJ post that were not supported by any sort of measurement or even simulation. I don't recall the details. > In each case, the lowest inductance achievable was always the goal. The > small deltas may be small in nanoHenrys but are probably a significant > percentage. Not inductance, impedance. I don't care about inductance if I can keep the impedance low over the frequency range that matters to my design. The small deltas in inductance only move the SRF, they don't have a large impact on the impedance after you mix the capacitor values. > Same-side vias are better for a cap than end vias. Vias in pad are better. > Partial vias in pad are best. That's the understanding I got. Yes, but none are really bad and it is a cost (or design/fab effort) vs. benifit. Same-side vias are pretty much free in all respects. Via in pad has some design effort if you have not done it before and some PCB vendors don't like to make them (but that varies). Partial vias (I assume you mean blind) are very expensive and clearly not worth the effort unless you are doing some really high freq work. Even then, I don't think they are needed for making the power delivery work well. Blind vias might be warranted in the signal path when you get near 10 GHz or so, but this is what I am remembering from the class, not anything I have seen myself. Ritchey was pretty impressive because he always uses the simplest methods and verifies that it will work before he builds the actual board. I don't beleive he said he has ever used vias in pads even with near 5 GHz boards. > A distribution of capacitance can give a superb, flat impedance over a wide > frequency range. Resonance is a problem for low ESR caps too far apart in > frequency such that they cancel each other out with an LC resonance between > the SRFs of the two values. Vias in pads provide better performance. How much better? If your design is so critical that you need to put the vias in the cap pads, then likely you need to do a careful simulation of the power distribution to see exactly what you have rather than to rely on general guidelines that may or may not allow a given design to work.Article: 107518
rickman wrote:
> Personally I think most problems in using HDLs in this way come not
> directly from the way signals or variables are used, but rather from
> the use of an HDL to describe the solution in an abstract way.
The problem is not that it can't be done
but rather a lack of tradition and good examples
of what the present generation of synthesis
tools can do if I let them.
-- Mike Treseler
Article: 107519MM wrote: > <pmaupin@gmail.com> wrote in message > > Where can I find the ASCII package files? > > Try this link: > http://www.xilinx.com/products/silicon_solutions/fpgas/virtex/virtex4/resources/virtex-4-pkgs.htm > > To get there from the page where you started you should have chosen All > Virtex-4 Resources and then Package Files under the Documentation... > > /Mikhail Thanks! PatArticle: 107520
MM wrote: > > Where can I find the ASCII package files? > > Try this link: > http://www.xilinx.com/products/silicon_solutions/fpgas/virtex/virtex4/resources/virtex-4-pkgs.htm > > To get there from the page where you started you should have chosen All > Virtex-4 Resources and then Package Files under the Documentation... > Even there, not all the links are correct. For example the FF1513 links (LX100, LX160, LX200) all point to the same file (LX100 version). A bit of URL jiggery-pokery seems to lead to the right files, though, so I think I'm good. Thanks, PatArticle: 107521
"Antti" <Antti.Lukats@xilant.com> wrote: >neha.karanjkar@gmail.com schrieb: > >> Hi all. >> I'm an undergrad student doing a year long project on designing an 8051 >> variant for FPGA. >> We're required to decide upon the specifications, by targeting any >> particular application. >> I'd be really thankful for any suggestions for the applications.... >> Could someone guide me to sites that offer a comparison, & >> applications of available 8051 cores? >> >> thanx in advance > >there are many many many free and commercial 8051 derivates. spending a >year to make another clone really doesnt make sense unless there is >something around the 8051 that makes the whole SoC different from the >current offerings. I agree. If they want to make something usefull, they should try to clone an MSP430 (which is probably much easier as well). -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 107522
neha.karanjkar@gmail.com wrote: > Hi all. > I'm an undergrad student doing a year long project on designing an 8051 > variant for FPGA. > We're required to decide upon the specifications, by targeting any > particular application. > I'd be really thankful for any suggestions for the applications.... > Could someone guide me to sites that offer a comparison, & > applications of available 8051 cores? > > thanx in advance Here are some ideas, that would be both educational, and usefull. Make the application "FPGA soft-cpu" - so that covers 8051+integration aspects. Then, take all the 8051-cores you can find, and compile and benchmark them, and publish those results in a table. You will need to include a test suite, to verify they actually work. Next, look at a FPGA-centric core, like the Open Source mico-8, from lattice (or PacoBlaze) : Note the speeds, and Sizes. Follow the lead of these designs, and make your 80C51 _variable_ in scope. eg to make a smaller CPU, try for a subset of 80C51, that maps onto FPGA fabric better. Read up on the 8048 core, which was the precursor to the 80C51. Some things to try : * Add a debug-engine, with an A5H trap opcode. * Make MUL and DIV opcodes conditional, and/or mapped onto hardware * Extend MUL & DIV on FPGA devices with HW maths resource * make IDATA and DATA opcodes conditional * Extend the stack pointer to 9 bits * Add a register frame pointer * remove AJMP/ACALL and/or remove LJMP/LCALL * remove all/some of the Boolean opcode engine * Overlay Code and data ie you are looking to _shrink_ the 8051, but keep it compatible with existing tools, when used with care! If you restrict to assembler, you should be able to create a much smaller "8048 resourced 80C51", for example. Working with compilers+subset would get more interesting, and you would certainly need an opcode trap system, as well as SW tools to sift 80C51 HEX files :) -jgArticle: 107523
linnix wrote: > We can book a 7 days cruise from LA to Mexico and do hand-on > training/experiments with FPGA. How many are coming? Can you post more information about place, price, dates,concept etc.. thanksArticle: 107524
"rickman" <gnuarm@gmail.com> wrote in message news:1156880090.093192.209290@m73g2000cwd.googlegroups.com... > John_H wrote: >> "rickman" <gnuarm@gmail.com> wrote in message >> Won't any higher inductance result in the same above-SRF slope? That is, >> given the total inductance, it won't matter what the capacitance is once >> above an ohm in the impedance vs freq plot. > > I'm not sure what you are asking. A different capacitance will not > change the inductive part of the impedance curve and a different > inductance will not change the capacitive part of the curve. What > changes in both cases is the SRF. So you put a few 0.1 uF caps on the > board and a number more of 0.01 uF caps and even more of the 0.001 uF > caps. Each capacitance value needs to have sufficient quantity to > bring the impedance near the SRF low enough to be effective. Then the > capacitive effect of the smaller caps keep the overall impedance low in > spite of the larger caps being inductive. Finally the impedance of the > ground planes keep the impedance low for the highest frequency. Doing > a simulation is always a good thing to be able to see how the parallel > resonances affect the impedance. The discussion was on inductance with vias. If you have 1nH of series impedance, at 1 GHz it doesn't matter what your capacitance is, you'll have a degraded impedance based primarily on th L. If you have 1/4 nH series inductance, you have a 4x improvement in this high-frequency impedance. L matters for more than just SRF. >> I've seen good information on Cadence tools based on Sun Microsystems >> work >> that tracks what you've described with Ritchey. A recent Howard Johnson >> / >> Xilinx talk also covered many of these items well without contradiction. > > The contradiction part I don't agree with. Many still argue that the > distance between the IC and the cap is critical and some still say > quantity is more important than variety of SRF. In one of these > threads there was a link to a post by HJ. There were some things in > the HJ post that were not supported by any sort of measurement or even > simulation. I don't recall the details. Neither the tool nor the talk suggested location is critical. I agree with you that the distance isn't terribly critical. If you have good planes - even the swiss cheese under an FPGA - your sub-nH plane inductance to the more distant cap has an adequate connection. The rule of thumb I understood was to keep the cap within ~1/10 wavelength of the frequencies of interest. The placement for a 300 MHz SRF cap is more critical than a 30 MHz SRF bulk device. I agree with you completely on this. "As close to the pin as possible" is pretty silly; unless you don't have good planes, then go for it. >> In each case, the lowest inductance achievable was always the goal. The >> small deltas may be small in nanoHenrys but are probably a significant >> percentage. > > Not inductance, impedance. I don't care about inductance if I can keep > the impedance low over the frequency range that matters to my design. > The small deltas in inductance only move the SRF, they don't have a > large impact on the impedance after you mix the capacitor values. The small deltas in inductance directly affect the impedance above the SRF when the L is dominant on the impedance. The frequency of interest may be above the SRF but the cap still makes a darn good bypass, retaiing the low (though increasing) impedance as the frequency increases above the Series Resonant Frequency. >> Same-side vias are better for a cap than end vias. Vias in pad are >> better. >> Partial vias in pad are best. That's the understanding I got. > > Yes, but none are really bad and it is a cost (or design/fab effort) > vs. benifit. Same-side vias are pretty much free in all respects. Via > in pad has some design effort if you have not done it before and some > PCB vendors don't like to make them (but that varies). Partial vias (I > assume you mean blind) are very expensive and clearly not worth the > effort unless you are doing some really high freq work. Even then, I > don't think they are needed for making the power delivery work well. > Blind vias might be warranted in the signal path when you get near 10 > GHz or so, but this is what I am remembering from the class, not > anything I have seen myself. For the really high frequencies, the form factor of the board plays a huge part with open-end transmission line effects felt as the power planes end at the board edge. The higher inductance lowers your SRFs and increases the impedance above your SRF-tuned "floor" possibly still within your frequencies of interest. All the improved inductance delivers in the end is a better impedance for when you can't provide any better SRFs. > Ritchey was pretty impressive because he always uses the simplest > methods and verifies that it will work before he builds the actual > board. I don't beleive he said he has ever used vias in pads even with > near 5 GHz boards. I'll probably look into getting his book - it sounds like good, hard science and engineering. The rare stuff. >> A distribution of capacitance can give a superb, flat impedance over a >> wide >> frequency range. Resonance is a problem for low ESR caps too far apart >> in >> frequency such that they cancel each other out with an LC resonance >> between >> the SRFs of the two values. Vias in pads provide better performance. > > How much better? If your design is so critical that you need to put > the vias in the cap pads, then likely you need to do a careful > simulation of the power distribution to see exactly what you have > rather than to rely on general guidelines that may or may not allow a > given design to work. I would recommend good power distribution simulation. The tools haven't been so useful and available to the engineers now used to doing IBIS and spice simulations for signal integrity. The tools that are available aren't cheap, either. Proper modeling of the current sources are also a bit of a trick that wouldn't come easy to the average designer. ____ I would guess the biggest need for the extreme measures is bridging between the discrete capacitors and the disctributed capacitance of the board planes. At 10 Ghz, one might be relying entirely on the distributed capacitance. It's the ~1GHz range that might be the hardest to deal with. Simulations can show how much of a "hole" there is between caps and distributed capacitance. This hole can be addressed with unusual capacitors, vias in pad, or simply not addressed at all. Even with solid engineering, there's still a bit of an art. I appreciate the refresh and reevaluation of my own stance on capacitors. Last time I came out about the distributed values, there were a large number of naysayers in this group. The more real-world literature we have out there - such as Ritchey's book - and the more engineers that realize the interplay, the better we'll all be able to design. For us in comp.arch.fpga, much of our success comes from the silicon vendors providing good power distribution on both the silicon *and* the packaging since our BGAs start to lose sight of the board impedance above many of the frequencies we're worrying about. Discretes on our boards are still affected by our power decoupling approach but the FPGAs start off into a world of their own within their packages.
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