deglitching a clock

John Larkin wrote:
> On 29 Mar 2006 01:00:59 -0800, bill.sloman@ieee.org wrote:
>
> >
> >John Larkin wrote:
> >> On 28 Mar 2006 12:45:23 -0800, bill.sloman@ieee.org wrote:
> >>
> >>
> >> >So the Fpga to Fpga routing worked - good.
> >>
> >> That's not what we did. We designed a clock deglitcher to go inside
> >> the FPGA.
> >
> >Enough propagation delays to cover the dwell at the switching
> >threshold, and a state machine to make sure that the clock only changes
> >state once in that interval?
>
>
> We did my original #2 suggestion, a tapped delay line driven from the
> pin, driving an r-s flipflop. Set the flop if all the taps are 1s,
> clear it if all are 0s. Sort of a poor man's 1-bit FIR lowpass filter.
> The delay line is a string of eight buffers, about 10 ns overall.
>
> We'd have done Peter's circuit if we'd learned of it sooner.
>
> It's interesting that my post evoked two classes of response:
>
> 1. It can't be done, don't do it, kluge the boards (also the official
> Xilinx response!)

I think I'm in that catagory, though I'd describe my response as saying
that it shouldn't be done in software - if for no other reason than
that the dwell time at 1.2V eats into your timing error budget - and
that the time you'd already spent on looking for a software solution
should have been enough to find one (which turns out to have been
correct).

> 2. Yes, and here are my ideas on how you could do it/how I've already
> done it/interesting asides.

Granting that I was fixated on the hardware solution, I did suggest how
you might hack the board, based on a problem that I'd been a party to,
many years ago.

-- 
Bill Sloman, Nijmegen

John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

>On Tue, 28 Mar 2006 08:55:50 +1200, Jim Granville
><no.spam@designtools.co.nz> wrote:
>
>>John Larkin wrote:
>>
>>> Some ideas:
>>> 
>>> 1. Use the DCM to multiply the clock by, say, 8. Run the 16 MHz clock
>>> as data through a dual-rank d-flop resynchronizer, clocked at 128 MHz
>>> maybe, and use the second flop's output as the new clock source. A
>>> Xilinx fae claims this won't work. As far as we can interpret his
>>> English, the DCM is not a true PLL (ok, then what is it?) and will
>>> propagate the glitches, too. He claims there *is* no solution inside
>>> the chip.
>>> 
>>> 2. Run the clock in as a regular logic pin. That drives a delay chain,
>>> a string of buffers, maybe 4 or 5 ns worth; call the input and output
>>> of the string A and B. Next, set up an RS flipflop; set it if A and B
>>> are both high, and clear it if both are low. Drive the new clock net
>>> from that flop. Maybe include a midpoint tap or two in the logic, just
>>> for fun.
>>> 
>>> 3. Program the clock logic threshold to be lower. It's not clear to us
>>> if this is possible without changing Vccio on the FPGAs. Marginal at
>>> best.
>>> 
>>> 
>>> Any other thoughts/ideas? Has anybody else fixed clock glitches inside
>>> an FPGA?
>>
>>Enable the schmitt option on the pin :)
>
>Don't I wish! There is a programmable delay element in the IO block,
>but it's probably a string of inverters, not an honest R-C delay, so
>it likely can't be used to lowpass the edge. We're not sure.
>
>I wish they'd tell us a little more about the actual electrical
>behavior of the i/o bits. I mean, Altera and Actel and everybody else
>has snooped all this out already.

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

On Fri, 31 Mar 2006 16:40:39 GMT, nico@puntnl.niks (Nico Coesel)
wrote:


>>
>>I wish they'd tell us a little more about the actual electrical
>>behavior of the i/o bits. I mean, Altera and Actel and everybody else
>>has snooped all this out already.
>
>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.

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:

>>I wish they'd tell us a little more about the actual electrical
>>behavior of the i/o bits. I mean, Altera and Actel and everybody else
>>has snooped all this out already.
> 
> 
> Xilinx is good with keeping information under their hat. One of the

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

> 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.

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

"Nico Coesel" <nico@puntnl.niks> wrote in message 
news:442d5a9f.1639975980@news.kpnplanet.nl...
> 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.

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?) 

John  Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

>On Fri, 31 Mar 2006 16:40:39 GMT, nico@puntnl.niks (Nico Coesel)
>wrote:
>
>
>>>
>>>I wish they'd tell us a little more about the actual electrical
>>>behavior of the i/o bits. I mean, Altera and Actel and everybody else
>>>has snooped all this out already.
>>
>>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.
>
>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.

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.

>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 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

Falk Brunner <Falk.Brunner@gmx.de> wrote:

>Nico Coesel schrieb:
>
>>>I wish they'd tell us a little more about the actual electrical
>>>behavior of the i/o bits. I mean, Altera and Actel and everybody else
>>>has snooped all this out already.
>> 
>> 
>> Xilinx is good with keeping information under their hat. One of the
>
>Really? I doubt it. And NO, Iam not paid by Xilinx ;-)

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

In article <p6nq22l4nf53kqanjhu7d4ojn70nb933nm@4ax.com>,
John Larkin  <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
[....]
>I wonder if anyone has ever kluged a bga layout, sort of like one of
>those jellyfish with a thousand tentacles.

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

Ken Smith wrote:

> In article <p6nq22l4nf53kqanjhu7d4ojn70nb933nm@4ax.com>,
> John Larkin  <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
> [....]
> 
>>I wonder if anyone has ever kluged a bga layout, sort of like one of
>>those jellyfish with a thousand tentacles.
> 
> 
> 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.

  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

In article <442df4ce$1@clear.net.nz>,
Jim Granville  <no.spam@designtools.co.nz> wrote:
>Ken Smith wrote:
>
>> In article <p6nq22l4nf53kqanjhu7d4ojn70nb933nm@4ax.com>,
>> John Larkin  <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
>> [....]
>> 
>>>I wonder if anyone has ever kluged a bga layout, sort of like one of
>>>those jellyfish with a thousand tentacles.
>> 
>> 
>> 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.
>
>  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 !?"  :)

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