async clk input, clock glitches

Antti wrote:

> failing circuit
> 
> ASIC outpu t> 15mm trace > connector > 5mm trace > 27 ohm > 3mm trace
> FPGA input >
> 
>>F-F strobed with 50mhz > global clock buffer > 2 bit counter
> 
> 
> now, this 2 bit counter sees
> * double clock from asic in about 1:10M pulses
> * missing clock from asic in about 1:100m pulses
> 
> the asic clock is know to be perfect many other devices can receive it
> and have 0 error rate (have not seen error ever!)
> the 50mhz clock signal quality, well it doesn matter, as whatever
> could be wrong, it could not explain the double and missing pulse
> counts ?
> 
> using PLL on 4mhz is not an option as it is not free running clock but
> byte strobe with 4mhz pulses
OK, how long does the data stay available after the strobe?  If greater 
than 20 ns,
you can register the 4 MHz clock and then clock the data bits by 
enabling the register.  If the data has to be clocked from the 4 MHz, 
then you can use the 4 MHz as a clock to the register, and set a bit, 
too.  That bit tells another register to copy the data from the register 
that is clocked by the 4 MHz clock.  So, you crossing the clock boundary 
at the already latched parallel data, not the clock itself.  You can put 
whatever filtering is needed in to qualify the 4 MHz clock edges, if 
needed, like reject any clock edge within 40 ns of one that you accepted.

Jon

Antti wrote:

> after that I did remove some of the logic from FPGA (not related to
> the "counter") freeing some 30% of the FPGA, dropping FPGA utilization
> from 82 to 54%
> 
> and the error rate dropped
> * double strobes: 1:500M
> * missing strobes: 0, - not happened yet, still running long term test
> 
Ugh!  Analog FPGAs!  Something I don't want to hear about!!!!  You may 
want to look at these clocks (both of them) with a fast analog scope or 
a really good digital one.  Even if the 4 MHz clock is extremely clean 
with great rise/fall times, if the 50 MHz is noisy or has slow edges, 
you'd hardly know the difference.  What I'm trying to say is jitter or 
double clocking of the 50 MHz clock could foul up the relationship 
between it and the 4 MHz, although I guess it would have to be truly 
horrible to do that, and the symptoms would undoubtedly show up 
somewhere else, too.  Is the 50 MHz processed by PLLs?  Noisy power 
could affect the locking of the PLL.  Good luck, but I doubt you are
going to really nail this without serious scope probing.

Jon

On Apr 2, 3:57=A0pm, Jon Elson <el...@wustl.edu> wrote:
> Antti wrote:
> > after that I did remove some of the logic from FPGA (not related to
> > the "counter") freeing some 30% of the FPGA, dropping FPGA utilization
> > from 82 to 54%
>
> > and the error rate dropped
> > * double strobes: 1:500M
> > * missing strobes: 0, - not happened yet, still running long term test
>
> Ugh! =A0Analog FPGAs! =A0Something I don't want to hear about!!!! =A0You m=
ay
> want to look at these clocks (both of them) with a fast analog scope or
> a really good digital one. =A0Even if the 4 MHz clock is extremely clean
> with great rise/fall times, if the 50 MHz is noisy or has slow edges,
> you'd hardly know the difference. =A0What I'm trying to say is jitter or
> double clocking of the 50 MHz clock could foul up the relationship
> between it and the 4 MHz, although I guess it would have to be truly
> horrible to do that, and the symptoms would undoubtedly show up
> somewhere else, too. =A0Is the 50 MHz processed by PLLs? =A0Noisy power
> could affect the locking of the PLL. =A0Good luck, but I doubt you are
> going to really nail this without serious scope probing.
>
> Jon

Well, if you worry about double-clocking, there are simple bad-aid
fixes that let you live with the double edges: click on
http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcel...
which shows two different ways to avoid the effect of double-edges on
a clock.
I wrote that long ago, and published it in Xilinx XCell magazine #34
Peter Alfke (repeat of my posting of several days ago)

On Apr 2, 4:49=A0pm, Peter Alfke <pe...@xilinx.com> wrote:
> On Apr 2, 3:57=A0pm, Jon Elson <el...@wustl.edu> wrote:
>
>
>
> > Antti wrote:
> > > after that I did remove some of the logic from FPGA (not related to
> > > the "counter") freeing some 30% of the FPGA, dropping FPGA utilization=

> > > from 82 to 54%
>
> > > and the error rate dropped
> > > * double strobes: 1:500M
> > > * missing strobes: 0, - not happened yet, still running long term test=

>
> > Ugh! =A0Analog FPGAs! =A0Something I don't want to hear about!!!! =A0You=
 may
> > want to look at these clocks (both of them) with a fast analog scope or
> > a really good digital one. =A0Even if the 4 MHz clock is extremely clean=

> > with great rise/fall times, if the 50 MHz is noisy or has slow edges,
> > you'd hardly know the difference. =A0What I'm trying to say is jitter or=

> > double clocking of the 50 MHz clock could foul up the relationship
> > between it and the 4 MHz, although I guess it would have to be truly
> > horrible to do that, and the symptoms would undoubtedly show up
> > somewhere else, too. =A0Is the 50 MHz processed by PLLs? =A0Noisy power
> > could affect the locking of the PLL. =A0Good luck, but I doubt you are
> > going to really nail this without serious scope probing.
>
> > Jon
>
> Well, if you worry about double-clocking, there are simple bad-aid
> fixes that let you live with the double edges: click onhttp://www.nalanda.=
nitc.ac.in/industry/appnotes/xilinx/documents/xcel...
> which shows two different ways to avoid the effect of double-edges on
> a clock.
> I wrote that long ago, and published it in Xilinx XCell magazine #34
> Peter Alfke (repeat of my posting of several days ago)

sloppy typing: I meant "band-aid fixes", since some purists insist
that it is bad practice to live with such a problem. But I prefer a
band-aid to the alternative of spreading blood all over the place or
even bleeding to death.
Peter

Hi Peter,

On 3 Apr., 01:49, Peter Alfke <pe...@xilinx.com> wrote:

> Well, if you worry about double-clocking, there are simple bad-aid
> fixes that let you live with the double edges: click onhttp://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcel...
> which shows two different ways to avoid the effect of double-edges on
> a clock.
> I wrote that long ago, and published it in Xilinx XCell magazine #34

I was curious about that article. I don't currently have any related
problem but learning these tricks might help me down the road.

Unfortunately the link you posted is dead. I tried to dig it up from
the xcell archives on xilinx.com, but the last issue available is #48.
It would be nice to have the older issues available as well,
especially for newcomers who can still learn some basic/historical
stuff from that.

Do you know another archive?

Greetings, Torsten

> I was curious about that article. I don't currently have any related
> problem but learning these tricks might help me down the road.
>
> Unfortunately the link you posted is dead. I tried to dig it up from
> the xcell archives on xilinx.com, but the last issue available is #48.
> It would be nice to have the older issues available as well,
> especially for newcomers who can still learn some basic/historical
> stuff from that.


Here's the full link Peter posted a couple of days ago...

http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcell/xl34/xl34_54.pdf



Nial 

Torsten Landschoff wrote:
>
> Do you know another archive?
>
archive.org 

On Thu, 3 Apr 2008 00:33:33 -0700 (PDT), Torsten Landschoff
<t.landschoff@gmx.de> wrote:

>Hi Peter,
>
>On 3 Apr., 01:49, Peter Alfke <pe...@xilinx.com> wrote:
>
>> Well, if you worry about double-clocking, there are simple bad-aid
>> fixes that let you live with the double edges: click onhttp://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcel...
>> which shows two different ways to avoid the effect of double-edges on
>> a clock.
>> I wrote that long ago, and published it in Xilinx XCell magazine #34
>
>I was curious about that article. I don't currently have any related
>problem but learning these tricks might help me down the road.
>
>Unfortunately the link you posted is dead. I tried to dig it up from
>the xcell archives on xilinx.com, but the last issue available is #48.
>It would be nice to have the older issues available as well,
>especially for newcomers who can still learn some basic/historical
>stuff from that.
>
>Do you know another archive?
>
>Greetings, Torsten

For an official source of older XCell magazines go here:
ftp://ftp.xilinx.com/pub/documentation/xcell/00_index.htm

the specific issue is here:
ftp://ftp.xilinx.com/pub/documentation/xcell/xcell34.pdf

with the article starting on page 54.

On 2 Apr., 18:22, Antti <Antti.Luk...@googlemail.com> wrote:
> On 1 Apr., 14:31, "Nial Stewart"
>
> <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > I've read all the posts here but have lost track of how you're
> > getting on.
>
> > Can you post an update and describe what the problem turned out
> > to be?
>
> > Nial.
>
> Quote from Actel website: "In March 2008, it was discovered that a
> potential advanced optimization could cause a logic gating of a global
> signal. This optimization is part of a set of other routing
> optimizations that could be invoked if a user sets the Routing High
> Effort Mode in the Advanced Option of the Layout."
>
> This is fixed in Libero 8.3 released march 31 2008
>
> I use the exact target device and setting as described at actel
> website, so I assume at least some of the mess i have had may as well
> be caused by this global signal gating in high effort mode.
>
> Folks, dont think I am not trying hard enough, I am, but the tools
> sometimes choke as well. The code that I currently have, and that is
> randomly failing, whatever constraints, in any normal FPGA fabric with
> no tool injected mess, it SHOULD WORK, but it isnt.
>
> Of course, the tools should be the last thing to blaim on, but
> sometimes they are the root of evil
>
> I try the 8.3 tools and hope it is fixing the issues i have
>
> Antti

updating to 8.3 did not fix the problems, but I am getting closer
status:

in desing exist async strobes A1, A2 (A1 byte rd/wr strobe, A2 spi
slave from ext mcu)

loadable LFSR in A1 domain
2:1 MUX for the selecting the load value
1 input of mux = const, loaded at powerup
2 input of mux connected to 24 bit shift register in A2 domain

LFSR is loaded with constant at powerup, and loaded
with current value in spi shift register ONCE, after
that load the load enable signal is FULLY DISABLED

now, the actual loads to the LFSR work 100%

but when the there is data shifted in into the spi shift
register connected to the input mux of the LFSR load input
then some sequences of data make the LFSR content corrupt

these sequences are REPEATABLE, that is not random!

for different FPGA implementiation runs the sequences are
different, but still for given PCB/FPGA bitstream they are
constant. That is the LFSR gets corrupted at certaing
values being visible on the load input via mux

I already have forced the LFSR enable and mux select
to global clocks
of course the SPI clock and LFSR clocks are global
clocks as well

Antti

On Fri, 4 Apr 2008 23:56:37 -0700 (PDT), Antti <Antti.Lukats@googlemail.com>
wrote:

>On 2 Apr., 18:22, Antti <Antti.Luk...@googlemail.com> wrote:
>> On 1 Apr., 14:31, "Nial Stewart"
>>
>> <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
>> > I've read all the posts here but have lost track of how you're
>> > getting on.
>>
>> > Can you post an update and describe what the problem turned out
>> > to be?
>>
>> > Nial.
>>
>> Quote from Actel website: "In March 2008, it was discovered that a
>> potential advanced optimization could cause a logic gating of a global
>> signal. 

>> This is fixed in Libero 8.3 released march 31 2008

>updating to 8.3 did not fix the problems, but I am getting closer
>status:

>in desing exist async strobes A1, A2 (A1 byte rd/wr strobe, A2 spi
>slave from ext mcu)
>
>loadable LFSR in A1 domain
>2:1 MUX for the selecting the load value
>1 input of mux = const, loaded at powerup
>2 input of mux connected to 24 bit shift register in A2 domain
>
>LFSR is loaded with constant at powerup, and loaded
>with current value in spi shift register ONCE, after
>that load the load enable signal is FULLY DISABLED

>but when the there is data shifted in into the spi shift
>register connected to the input mux of the LFSR load input
>then some sequences of data make the LFSR content corrupt
>
>these sequences are REPEATABLE, that is not random!

As I understand it, the SPI register and the LFSR register are on different
clock domains; with purely combinational logic (the mux, and the Load Enable)
between them.

In Xilinx, as I understand it, if a 4-Lut transitions between one
Load_Enable=FALSE state, and another Load_Enable=FALSE state, it is guaranteed
not to glitch via a Load_Enable=True state. 

I don't know Actel at all - is the same guarantee true there?

If not, I believe you need an intermediate register (just a simple pipeline
register) clocked in the LFSR clock domain, to hold a copy of the SPI shift
register. (This copy is subject to metastability, but with a tiny window of
opportunity). Whereas now, you are exposed to the possibility of glitches
derived from the SPI clock, and latched on the LFSR clock.

> That is the LFSR gets corrupted at certaing
>values being visible on the load input via mux

... or certain TRANSITIONS being visible on the load input?

IF the mux and the load enable logic are rolled into the same combinational
cloud, AND 0->0 via glitch 1 is possible, then you are exposed to invalid values
during a settling time window after the ... wrong clock.

>I already have forced the LFSR enable and mux select
>to global clocks

I'm not sure that helps (it may reduce errors by an order of magnitude or more,
but it leaves you open to the possibility above)

>of course the SPI clock and LFSR clocks are global
>clocks as well
... good...

just a guess but on the information given, it looks plausible to me.

- Brian