deglitching a clock

Jeeze, I wonder why so few real-world issues and solutions are discussed here.

Best regards, Spehro Pefhany

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Xilinx is good with keeping information under their hat. One of the projects I'm currently working on needs a re-design of the PCB because the pin arrangement I had in mind is simply not possible. But the datasheet and application notes don't mention a word about limits on IOBs.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Can you be more specific about what went wrong? I thought I knew all the (many) rules about i/o pin behavior and grouping. It's quite a puzzle already.

We always pre-assign pins based on what the pcb layout prefers, and design the fpga concurrently with the pcb layout, or more often after it's been sent out to etch. Your situation sounds scairy.

I wonder if anyone has ever kluged a bga layout, sort of like one of those jellyfish with a thousand tentacles.

John

Nico Coesel schrieb:

Really? I doubt it. And NO, Iam not paid by Xilinx ;-)

What was the problem? Often enought, people tend to just fly over the datasheets, instead of studing them carefully. All those tiny little footnotes . . .

Regards Falk

Since I've never had an IOB problem in the several generations of Xilinx families I've designed with, what information was lacking from your perspective? (And what device family?)

Whatever people's opinion on the validity of the fix, I think that it's a good time for your engineering team to do some introspection. Think about why this problem wasn't detected before shipping the boards to customers? Should you do some signal integrity checks when bringing up new boards? Have you run the boards in a thermal chamber? Does it make sense to vary the supply voltages too? Should you develop a checklist so that it won't happen again? Etcetera...

We only sent one V450 to a customer, and that was a freebie, so that they could start writing drivers. We knew something was sometimes slightly funny, but it mostly worked, and we told the guy that it was a beta and would likely need changes. It was during testing here that we looked into the strangeness in detail and found the clock problem.

There are about 10 V470's in the field. They have the same clock and fpga's and the same basic layout, but for some reason they all work fine. We will nevertheless upgrade them with the clock deglitcher.

And we sure will be more careful about oscillators and clock distribution in the future... everything's getting too fast. It was probably the move of the ground plane to layer 5 of 6 (the clock is mostly routed on 6), and the fast/weak xo, that caused the problem. Clock-on-the-bottom isn't ideal for noise immunity, either.

Here's the gadget, but you can't see anything relevant in this pic, just barely the last FPGA in the clock string at the top...

The xo is near the bottom, between the metal cover and the eprom, the dark thing poking out.

John

I've designed a DDR200 memory interface in a Spartan3 200k gates device. A quick introduction: DDR memory has a bi-directional data clock (DQS) which is driven by the memory when data is read and driven by the FPGA when the data is written into the memory. This means I need to use a local clock for every byte lane (4 lanes in total) to clock the data into the device or drive DQS from the internal clock. This caused 2 problems:

1) It turns out not every pin can be routed efficiently to form a low delay local clock to clock adjacent pins. Worse, only the top and bottom sides of the FPGA (the clock pins are on the left and right sides) feature real fast routing between IOBs. Determining the right pins to use is a trial-and-error process. 2) It also appears most IOBs are actually implemented as a dual IOB elements which share certain pins, including the clock pin. This means that it is not possible to have a DQS line share a 'dual IOB' with a data pin since two different clocks are required.

I can't find any references to these limitations in the datasheet. A DDR memory interface application note makes a short notice of some limitations on placement, but thats all there is.

I did manage to bypass these problems on my prototype with some additional wiring to connect the DQS to some unused pins and use an internal clock to capture the data. This works for now, but I don't want to put this solution into a production device.

I did the same. I designed the PCB first after studying the FPGA datasheet thouroughly. I even created the possibility to use the DCI (digitally controlled impedance).

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Another example: Several years ago I made JTAG programming routines for a Spartan 2 according to Xilinx application notes (verified bit by bit with a logic analyzer). For some reason these routines didn't work on a Spartan 2E device. I got it working in the end by thinking logically on how the device should be initialized to accept a configuration, but the result is definitely not according to Xilinx's documentation.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Hello John,

If you don't have one already get a fast FET probe. I find that an indispensable tool to check fast clocks and stuff. The usual resistive divider into a coax works as well but it's more clumsy. Good FET probes come with neat low inductance connection tools.

Nice. You guys sure do clean mechanical designs. At one client we provided a phone jack at the front through which the boards could be diagnosed and SW-upgraded. We even had some where you could connect a touch-tone phone and use its keypad to change some settings.

That was in the early 90's. Nowadays I guess it would be a USB jack or, gasp, a Bluetooth link.

Regards, Joerg

We have a TDS3052 (500 MHz) scope with the 1 GHz fet probes. Next would be the big ole 7104 (1 GHz) analog scope, with a 1 GHz fet probe. Our ultimate weapon is an 11801 with an SD-14 sampling head, .25 pF and 3 GHz at the probe tip. I love scopes.

Interestingly, the fpga glitch stopped when the TDS probe was touched on the clock pin of the 2nd FPGA, which added about 0.5 pF.

John

In article , John Larkin wrote: [....]

More likely it would be a costly blind-via PCB that sits between the BGA and the base PCB. (Vomit)

When I do a board with CPLD on it, I sometimes wire the unused pins together in some random arrangement. You can't get fast signals out and back but you can do a few slow ones.

On my current project I'm up to 380 out of 512 used. This is making me nervous.

--
--
kensmith@rahul.net   forging knowledge

Then I'll put the hex on this, by asking : " What could marketing possibly dream up, that could use more than the 132 spare pins !?" :)

-jg

I hate when that happens :)

The change in stackup might have made the problem worse, but daisy-chained clocks are a bad idea with high speed logic. It is better to star route them, with equal length lines from the clock driver to each destination with source termination resisters. For a fanout greater than 1, don't use the oscillator output directly, use it to drive a higher drive gate.

Daisy chaining clocks is bad for signal integrity and for clock skew.

-- Phil Hays

"John Larkin" a écrit dans le message de news: snipped-for-privacy@4ax.com...

On time we had a CPLD interfacing two asics together. Debugged the protos/first runs, temperature tests,... All OK. Then we had one particular board, tested OK in July/August which developped random failure when coming back from vacation in september. A bit of investigation revealed that the asic interface wasn't behaving according to the datasheet (wrong sampling clock front IIRC). It worked OK with the July/August high temperatures (timings were marginally OK). In September not anymore.

Whew, a few days later the client was launching a first 1000 boards run (CPLD soldered and not ISP). The boards were HDSL repeaters installed everywhere, often in particularly hard to access places.

--
Thanks,
Fred.

Yup.

I spent most of the night once on such a problem, on a SOIC on my first big SMT board. Probing anywhere else on the net - even a via half an inch away - didn't fix the problem, nor did series termination, parallel termination, or capacitive loading on the via.

Eventually the penny dropped - the significant parameter was not the probe's capacitance, but its _weight_. Somehow, of about 6000 joints on that board, this one had missed out on its dose of solder paste. A tiny spot of solder, and all was well.

- Brian

Actually, it is spare macro cells. Not all macro cells go to pins.

I'm more worried about stuff like this:

process(MemClock) ... if Request1 then Arb = "001" elsif Request2 Arb = "010" elsif Request3 Arb = "011" ... end process

Oh oh a bug! Request 7 may never get to happen if all the others are busy. It has got to get in at least now and then. I can add a couple of flip flops to see if Request7 has been true for more than a cycle of SlowClock and doctor the logic. Bummer! now it won't fit!

Telling marketing to "go fish" is easy compared to having to spin the PCB late in the development.

--
--
kensmith@rahul.net   forging knowledge

That's the first reaction my engineers usually have: "it must be a bad solder joint, and the pressure from the probe fixes it." They haven't been right so far.

John