cool BGA pattern

Duh. Basic capillary attraction is the engine, so if the capillary is already filled, there will be no (less) attraction.

Right. The plane sandwich is a great high-speed bypassing system. It needs help at lower frequencies, which is what the caps do. The caps don't need to be especially close the the FPGA.

I know one guy who doesn't use bypass caps at all, and his stuff works.

I do a lot of TDR testing on board traces and planes.

Simulation is OK if you can model the planes accurately. A lot of what I've seen doesn't. All I use is 0.33 uF 0603s, a few per FPGA per supply voltage. And every board has worked fine so far, including digital delay generators that pass a signal in/out of an FPGA three or four times and pick up under 30 ps RMS jitter.

John

Just curious, but what in specific are the biggest gripes? Is there a specific feature or features that are insanely broken? I've been a user since 1986 and certainly had/have much to complain about on the software, but I use it on almost a daily basis. Sure, there are various Xilinx tools that do things "the Xilinx way" instead of using the typical industry-standard method. I also use the Altera tools regularly and love/hate them as well.

Are you using high-density or lower-density parts? Which family?

Steve Knapp Prevailing Technology, Inc.

I don't drive the tools myself, but I have two very good guys who do. I negotiate architectures with them, and they do the actual design. A typical design takes 3 or 4 times as long as it should, because of tool problems. They tell me...

Schematic design (which we use for top level, and occasional special blocks) is broken. Always has been, just different versions of broken.

Asking for hard features (like, force this flop to be an i/o cell flop) is difficult and erratic. The tools like to just ignore what we want to do.

The Spartan6 DRAM controller couldn't be made to work. At 128 MHz! We gave up.

Things crash. Things give cryptic error messages. Placement makes no sense and wastes nanoseconds, even in low density apps. The GUI is flakey.

And lots of other gripes; I could ask them for a list. One of my guys took an existing design, all VHDL, and ported it to Altera in a couple of hours. It just worked.

Maybe the biggest problem is support. There may be simple things we could do to fix most of our problems, but "support" is in the business of retiring trouble tickets, not actually helping. And once they do close a ticket, you have to start all over, usually with someone else. And they apparently can't transfer the case to that someone else. We did have some decent people at NuHo who harassed Xilinx on our behalf, but you know what happened there.

Altera *sends smart people to our shop* when we need help.

Too bad. The Xilinx silicon is great. I'd been a Xilinx fan ever since Peter Alfke talked me into using Xilinx, after an accidental meeting of heads (literally, inside a big cardboard box full of books for sale) at the Foothill Flea Market. But my guys have convinced me that we should switch.

John

John,

I don't think your experience with Xilinx is typical. We have working hardware using Spartan 6 and DDR2 DRAM running at 333 MHz. I agree that there are support issues, and there are some things that are very hard to use, including the memory interface generator.

I'll also agree that schematics are broken, at least since they dumped Aldec after Foundation version 4.1i. It's pretty clear that schematics are very low on their software support priority list. I stopped using schematics when I moved from the Aldec-based Foundation tools to ISE.

However I have had very good luck with the back-end tools. There are a lot of switches in each tool and once you find the proper settings you can get very good results. I have also found that the recent versions of XST compare favorably to third-party tools like Synplify. Again there are a lot of knobs to turn to get the best performance from XST.

I hope someone from Xilinx listens to these threads. The real issue in your case seems to be the lack of support. I'm sure their bean-counters had a good reason to dump NuHorizons and get rid of most of the FAE's (there are still large Xilinx customers who get regular visits from Xilinx FAE's). However they should realize that you can only get so far with good silicon.

Good Luck, Gabor

In this respect they're just playing catch up with Altera, Quartus has used SDC files with Timequest for a couple of years now.

Nial

Point taken, but the point I was trying to make is there is a real concerted effort underway to improve quality, as well as comparability, standards support, etc. This effort has been underway for sometime, or so I'm told, and is about the bear fruit. (note: I don't know if this is the 13.x release, I just assume so?) I'm somewhat looking forward to what comes out - I know people are cynical, but I think it is a positive indication that action is being taken. SW quality to match the silicon is something we can all be happier about.

I think it would be worth feeding back some of the anecdotal issues people have had here to Xilinx - the issues that come from migration. the more information they have, the better they can react. Is there some e-mail or website where such feedback can be given directly and constructively?

When the vias are properly plated, there is no hole any more - it's just copper (with appropriate finish). The only thing you have to watch out for is that the plates should be flush with the rest of the surface - I have heard that some manufacturers have problems keeping them planar, and you end up with the plated vias being slightly higher than non-via pads. But that should not be a problem with a decent manufacturer.

You can leave the other end of the via open for marginally lower costs, or fill the hole and plate on the other side. This should be standard and error-free for a modern manufacturer.

That's my understanding of the theory too - you want your caps to be within a quarter wavelength and with low inductance paths to the pins. Mind you, the stuff I made isn't very high frequency, nor does it have a lot of transients.

Resonances are only a problem if you get peeks of high inductance or standing waves. The rule I use is to pick the smallest package production is happy using, then the largest capacitance in that package, and use that consistently. With the smallest package you get the smallest inductance - smaller capacitances in the same package are no better for bypassing at high frequencies, and worse at lower frequencies.

Avoid standing waves and resonance on the power planes by avoiding power planes - use polygons instead of planes, or add tracks to the power planes, so that there are no nice straight edges for reflecting waves.

But as I said, that's my theory - and I don't have the practice to back it up.

Planes are superb, low-impedance, low-Q bypass capacitors. The added discrete bypass caps just help the planes at low frequencies.

If you TDR a power:ground plane pair, it looks like an almost perfect capacitor with a little ESR (which is actually the transmission line impedance of the structure) and just hints of edge reflections. Seed it with randomly places caps, and it just gets better.

There are lots of dollars spent on courses and consultants that have bypassing theories, but on a multilayer board with power and ground planes, practically anything works. What can get tricky is things like Intel CPUs that idle at low current and need 50 amps in a few nanoseconds. But that's a low-frequency issue.

Hmmm, software or microcode could ramp those currents...

John

h.

Yes, smaller packages are lower inductance. But the resonance is from the inductance of the capacitor interacting with the capacitance of the power planes. Using multiple values of caps creates multiple resonances, but where one pair has a resonance another device has low impedance in parallel, so the net is a fairly low value across frequencies. The ESR of the caps prevents the resonance from being extremely high like a pure parallel LC circuit would be.

Yes, I've heard that theory, but Lee Ritchey debunked it IIRC. The effect of the capacitors attached to the planes swamps out the wave and the standing wave does not develop to any degree. but I won't say I am sure about how this works. I do remember that he could not find any issues with the standing wave effect. I wish I had the book handy. He had some good measurements to illustrate the matter.

Rick

gh.

nd

Or using async design rather than huge clock trees.

Rick

Quartus 10.0(sp1) is quite buggy and likes to crash. So nothing is perfect ;)

Overall the Altera software is better than Xilinx software. And the timing engine is better with sdc support etc.

--Kim

Yes, but planes are also low capacitance. The other way to think about this is that plane capacitance is very good at high frequency bypassing, and augments the normal bypass capacitors. I don't think the size of the plane makes a big difference, assuming you have other capacitors for the lower frequencies, so a polygon plane will do the same job. If I understand it correctly (and I know that's a big "if"), the inductance of the chip balls and pads will dominate the impedance of the plane capacitor to chip path.

My gut feeling here is that you are not going to get significant resonance between the power plane and the bypass capacitors, especially if the power "plane" is actually just a polygon, and therefore fairly small, while the capacitors are large. The power "plane" is then far too small in comparison to have a noticeable effect on the bypass capacitor, and therefore the bypass capacitor will work as expected. The power "plane" (viewed as a capacitor) is mainly for bypassing very high frequencies - these will be isolated from the bypass capacitors by the capacitors' inductance and ESR, thus it will also continue to work as expected.

And again the disclaimer - I haven't worked with this sort of thing in practice (the fastest card I have made was about 200 MHz), nor have I studied the theory or the maths here in detail. My theories are based on reading articles and guides, thinking about how things work, reading c.a.f., etc. I am posting here to ask and learn, and perhaps also to make the experts here think.

Actually, I thought the Aldec schematic tool was simply AWFUL, so bad I rigged up a system to use my preferred schematic entry (Protel 99) to generate architectural VHDL. It didn't make the VHDL quite the way Xilinx wanted it, so I had to hand edit - mostly to remove redundant duplications of library component declarations. But, I've been slowly learning the benefits of all-VHDL development, so this is much less an issue now than it was for me almost a decade ago. I still think their ise schematic is pretty bad, only slightly better than Aldec's, which seemsed like you could only get one gate and one FF on a page before the automated wire generator went nuts. Now, I can get 4 gates and 4 FFs on a page before the wiring gets messy. I mostly only use schematics for relatively simple, one-page glue logic for a CPLD, so it is OK.

Jon

Schematics would be nice for high-level design where dataflows tend to dominate the reader's interest. I've never seen a package that worked well enough to use, though. I just use schematics for board level. I've always used VHDL only for programmable parts.

OTOH, physical and logical viewers are useful to make sure synthesis is doing what the designer expects, though. The difference between such a viewer and a schematic entry package is the routing. The viewer doesn't (well) and the schematic capture package won't (you do). ;-)

Having done some playing with the Aldec Active-HDL block diagram editor, if you're in the market you may find it worth a look. For doing actual schematic entry of low level blocks it's only mediocre, but for tying together the high level stuff it's pretty quick and clean.

Market? Does it cost more than pocket lint? The Aldec rep has been bugging me to do a test drive, but there zero chance of spending money on such things.

The big advantage I see in schematic entry at the top level is documentation. Schematics are (well, can be) intuitive. A pile of VHDL is very difficult to dig through. Having had to verify a subsystem with a few hundred ~10K line files...

ote:

wly

eir

the

Fs on

for

ed well

ve always

s doing

ewer and a

nd the

bugging

ings.

ion.

ult to

line

You can do the reverse - write VHDL/Verilog and then get the schematic viewer in ISE to draw a representation of it for documentation. I've always thought it does a pretty good job of displaying the RTL view and giving a way to look at the hookup of top-level modules. PlanAhead can also generate schematics from the RTL source. Note - I'm just offering it here as an idea to facilitate documentation.