deglitching a clock

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

Yup, that's about ideal.

Skew doesn't matter here, and daisy chaining is fine *if* everything is done right, which it wasn't in this case. ECL clocks are usually daisy-chained... many small chips and picosecond skew requirements between nearby chips. Star fanout to 50 or so loads gets messy.

We're leaning towards slowing down the edge at the xo, maybe with an R-C or an HC-class buffer, and adding a tiny-logic schmitt buffer at each fpga, giving most of a volt of noise immunity. There's no room for star traces, or at least not without a lot of ripups. If we put the tinies on the bottom, under the fpga's, they fit nicely and we don't have to waste a bunch of hundreds of bucks on a new solder-paste stencil and reprogramming the pick-and-place.

Hey, the CPU has a clock-out pin, same freq as the clock-in in this case. We could use *that* to drive the two following FPGAs in the string. It's a 68332, ancient process cmos, swings hard and makes nice sedate edges! May as well leave the deglitcher in there, so we don't have to re-release the designs.

John

One of my customers screwed up the pinout on a largish microprocessor chip, *every pin*, and kluged it to work. It looked like a chip sitting on a ball of red yarn.

John

Hello John,

That increases phase noise. It may not matter in the digital world but I wouldn't do that for ADC clocks.

One technique I use if a home-run star system isn't practical is a nicely impedance controlled clock line (or a few) and then tapping off with low-C RF transistors wherever the clock is needed. It raises the hackles of the digital folks during design reviews but after a thorough explanation they like it.

That's how TV distribution used to be done in Europe, one line down from the roof and tapped off with -20dB couplers. At the very end there is a terminator. I use AC termination, mostly.

Regards, Joerg

I've had that happen, too! I laughed out loud reading your post. It is good to know that others in the world have gone through the same pain :) !

Take care, Rob

CATV systems still use backmatched taps, but the tap value drops the further you get from the amp. the systems I worked with were designed for a +10 dBm signal at the port on the tap to allow for four TVs per drop, and up to 4 dB loss in the drop and house wiring. It was an average sized system with 10,000 active drops, and 4,000 homes passed that didn't have service.

--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

The MC68340 is the same family as the MC68332. I saw a lot of MC68340 on the embedded controllers we built for the Microdyne 700 &

1620 series of telemetry equipment, as well as a satellite tracking controller that used a modified version of the same custom controller. They made a layout error for the 32,768 Hz oscillator that no one had noticed. It caused starting problems, and there was no way to fix it without changing the board layout.

--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

Emitter followers?

John