async clk input, clock glitches

Hi

FPGA has
1) 50mhz system clock from ext oscillator
2) 4Mhz clk that is async to the 50mhz

problem, the 4MHz clk input sees double clk pulse, error rate
approximate 1 to 10.000.000
unfortunatly the 4mhz clock needs to be used inside without phase
delay, so oversampling and filtering with 50mhz is not an option,
unless using very clever no delay glitch surpression filter

external small R/C circuit on 5mhz doesnt change the error rate much,
ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to
give better results as using the 4mhz clock directly

any ideas how to really clean the 4mhz clock?
or any thumb guess what is the likeliness to see double clk edges when
sampling 4mhz with async 50mhz?
could the "error rate" of such sampling be that 1:10M what I am
seeing?

I assume the 4 mhz clock is rather good, it coming from an ASIC and
has total wire lenght from asic to FPGA maybe 20 mm (but over PCB edge
connector). I did kinda think its hard to belive that the clock edge
is so slow or noisy that 50mhz sampling could ever see double/wrong
edges but guess i am wrong

it doesnt seem to be cross talk either, as there arent much IOs
toggling at all

hm it looks like in rare cases the error is also one clock pulse
missing!

:) any good suggestions are welcome, how to troubleshoot the issue

unfortunatly the FPGA is actel so can use any on-chip logic analyzer
core, and the chip is rather full also, some internal signal could be
routed out to external logic analyzer though if badly needed, but so
far i am trying to fix the issue by thinking, and error-retry...


Antti

"Antti" <Antti.Lukats@googlemail.com> wrote in message 
news:e6010199-ca1d-4540-8ae3-a69a3a23b106@b1g2000hsg.googlegroups.com...
> Hi
>
> FPGA has
> 1) 50mhz system clock from ext oscillator
> 2) 4Mhz clk that is async to the 50mhz
>
> problem, the 4MHz clk input sees double clk pulse, error rate
> approximate 1 to 10.000.000
> unfortunatly the 4mhz clock needs to be used inside without phase
> delay, so oversampling and filtering with 50mhz is not an option,
> unless using very clever no delay glitch surpression filter
>
> external small R/C circuit on 5mhz doesnt change the error rate much,
> ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to
> give better results as using the 4mhz clock directly
>
> any ideas how to really clean the 4mhz clock?
> or any thumb guess what is the likeliness to see double clk edges when
> sampling 4mhz with async 50mhz?
> could the "error rate" of such sampling be that 1:10M what I am
> seeing?
>
> I assume the 4 mhz clock is rather good, it coming from an ASIC and
> has total wire lenght from asic to FPGA maybe 20 mm (but over PCB edge
> connector). I did kinda think its hard to belive that the clock edge
> is so slow or noisy that 50mhz sampling could ever see double/wrong
> edges but guess i am wrong
>
> it doesnt seem to be cross talk either, as there arent much IOs
> toggling at all
>
> hm it looks like in rare cases the error is also one clock pulse
> missing!
>
> :) any good suggestions are welcome, how to troubleshoot the issue
>
> unfortunatly the FPGA is actel so can use any on-chip logic analyzer
> core, and the chip is rather full also, some internal signal could be
> routed out to external logic analyzer though if badly needed, but so
> far i am trying to fix the issue by thinking, and error-retry...
>
>
> Antti
>
>
If you are sure the $MHz tr and tf are within the device clock spec (as is 
the voltage) then try putting the 4MHz clock into an onboard PLL configured 
for zero delay and narrow bandwidth, then use the PLL output for internal 
clocking. (Being a low life Altera user, don't know if this is available in 
Xilinx parts) 

Antti wrote:

> Hi
> 
> FPGA has
> 1) 50mhz system clock from ext oscillator
> 2) 4Mhz clk that is async to the 50mhz
> 
> problem, the 4MHz clk input sees double clk pulse, error rate
> approximate 1 to 10.000.000
> unfortunatly the 4mhz clock needs to be used inside without phase
> delay, so oversampling and filtering with 50mhz is not an option,
> unless using very clever no delay glitch surpression filter

How much delay is allowed? I assume you have already latched the clock once
with every 50Mhz edge, to avoid meta stability problems. To avoid double
clock pulses, you could feed a shift register with this latched signal and
compare for "0111" and "1000" to detect edges more clean, maybe with an
additional holdoff after detection to avoid detecting spikes.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

On Sat, 29 Mar 2008 02:41:42 -0700 (PDT), Antti <Antti.Lukats@googlemail.com>
wrote:

>Hi
>
>FPGA has
>1) 50mhz system clock from ext oscillator
>2) 4Mhz clk that is async to the 50mhz
>
>problem, the 4MHz clk input sees double clk pulse, error rate
>approximate 1 to 10.000.000
>unfortunatly the 4mhz clock needs to be used inside without phase
>delay, so oversampling and filtering with 50mhz is not an option,
>unless using very clever no delay glitch surpression filter

however that doesn't stop you building analyzers (clocked on 50MHz) to diagnose
the problem

>external small R/C circuit on 5mhz doesnt change the error rate much,

series-term (22-50R) at source may be the best bet ... but with 20mm trace
length, that's unlikely to be the problem.

>ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to
>give better results as using the 4mhz clock directly

Also establishes that some sort of resynch is acceptable.

>any ideas how to really clean the 4mhz clock?
>or any thumb guess what is the likeliness to see double clk edges when
>sampling 4mhz with async 50mhz?

Metastability : about once in recorded human history :-) 
Other causes : e.g. crosstalk during the linear window : much higher.

>could the "error rate" of such sampling be that 1:10M what I am
>seeing?

>I assume the 4 mhz clock is rather good, it coming from an ASIC and
>has total wire lenght from asic to FPGA maybe 20 mm (but over PCB edge
>connector). I did kinda think its hard to belive that the clock edge
>is so slow or noisy that 50mhz sampling could ever see double/wrong
>edges but guess i am wrong
>
>it doesnt seem to be cross talk either, as there arent much IOs
>toggling at all
>
>hm it looks like in rare cases the error is also one clock pulse
>missing!

Build a trivial analyzer clocked at 50MHz. 
count "high time" and "low time" in 50MHz cycles; log the max and min "high
time" counts (update the log after each rising edge); ditto low time.

Good results would be 6 cycles min, 7 cycles max (+/-1 from asynchronicity)

Classic edge bounce will show min high (or low) time of 1 cycle; glitches  away
from edges (e.g. from major crosstalk) may show e.g. min high 1, min low 3
cycles. Missing pulses will show large "max" times.

etc

My guess would be min times of 1, i.e. double-clocking edges, from (small
amplitude) crosstalk which coincides with a slow 4MHz edge. 

Oh . And does this occur on one board, or on several identical ones?

- Brian

Antti wrote:
> Hi
>
> FPGA has
> 1) 50mhz system clock from ext oscillator
> 2) 4Mhz clk that is async to the 50mhz
>
> problem, the 4MHz clk input sees double clk pulse, error rate
> approximate 1 to 10.000.000
> unfortunatly the 4mhz clock needs to be used inside without phase
> delay, so oversampling and filtering with 50mhz is not an option,
> unless using very clever no delay glitch surpression filter
>
Hi Antti,

I guess your problem is a slow edge rate on your 4MHz clock. Does this fix 
it?

process(clk_50M)
  begin
    if rising_edge(clk_50M) then
      four_meg_d <= four_meg_in;
      four_meg_dd <= four_meg_d;
    end if;
  end process;

process(four_meg_in, four_meg_dd)
  begin
    if    four_meg_in = '1' and four_meg_dd = '0' then
      four_meg_out <= '1';
    elsif four_meg_in = '0' and four_meg_dd = '1' then
      four_meg_out <= '0';
    end if;
  end process;


HTH., Syms. 

On Mar 29, 10:41 am, Antti <Antti.Luk...@googlemail.com> wrote:
> Hi
>
> FPGA has
> 1) 50mhz system clock from ext oscillator
> 2) 4Mhz clk that is async to the 50mhz
>
> problem, the 4MHz clk input sees double clk pulse, error rate
> approximate 1 to 10.000.000
> unfortunatly the 4mhz clock needs to be used inside without phase
> delay, so oversampling and filtering with 50mhz is not an option,
> unless using very clever no delay glitch surpression filter
>
> external small R/C circuit on 5mhz doesnt change the error rate much,
> ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to
> give better results as using the 4mhz clock directly
>
> any ideas how to really clean the 4mhz clock?
> or any thumb guess what is the likeliness to see double clk edges when
> sampling 4mhz with async 50mhz?
> could the "error rate" of such sampling be that 1:10M what I am
> seeing?
>
> I assume the 4 mhz clock is rather good, it coming from an ASIC and
> has total wire lenght from asic to FPGA maybe 20 mm (but over PCB edge
> connector). I did kinda think its hard to belive that the clock edge
> is so slow or noisy that 50mhz sampling could ever see double/wrong
> edges but guess i am wrong
>
> it doesnt seem to be cross talk either, as there arent much IOs
> toggling at all
>
> hm it looks like in rare cases the error is also one clock pulse
> missing!
>
> :) any good suggestions are welcome, how to troubleshoot the issue
>
> unfortunatly the FPGA is actel so can use any on-chip logic analyzer
> core, and the chip is rather full also, some internal signal could be
> routed out to external logic analyzer though if badly needed, but so
> far i am trying to fix the issue by thinking, and error-retry...
>
> Antti

I am almost sure your 4Mhz frequency is clean on your board. But
verify!

If your 4MHZ is stable then the trouble is coming inside your FPGA.

Before all, verify you are using a Global buffer for the 50Mhz.

Then you have to register all inputs with your 50MHz and to register
the 4Mhz input with 50MHz too (f4mhz_reg). Then verify after Place &
Route, your are using IOB registers (registers in the PADs)!
The use of IOB registers is very important.
When this is done and verified, return to your code and add a new Flip-
Flop (50Mhz) to the registered 4Mhz input (f4mhz_reg2), and detect the
rising edge of the 4Mhz by

f4mhz_rise_pulse <= '1' WHEN (f4mhz_reg = '1') AND (f4mhz_reg2 = '0')
ELSE '0';

Finally, all your flip-flops inside the FPGA core should use 50Mhz clk
and the f4mhz_rise_pulse as clock enable.

I am almost sure this will resolve your design issue.
This is a very common issue for all VHDL / FPGA students .

Hoping this resolve the problem. But resolving the trouble is not
enough. We have to understand what was really the trouble and what
happen when we do not synchronize all inputs in 2 clock domain ?
Let me know if you want to understand what really was the trouble.

- Laurent
http://www.amontec.com
----
Introducing new USB Instrument Platform (Hi-Speed USB2.0 + Xilinx
FPGA ) in a very small format. Small as a Amontec JTAGkey !
New fast JTAG interface is coming with!

"Antti" <Antti.Lukats@googlemail.com> wrote in message 
news:e6010199-ca1d-4540-8ae3-a69a3a23b106@b1g2000hsg.googlegroups.com...
> Hi
>
> FPGA has
> 1) 50mhz system clock from ext oscillator
> 2) 4Mhz clk that is async to the 50mhz
>
> problem, the 4MHz clk input sees double clk pulse, error rate
> approximate 1 to 10.000.000

Not quite sure what you mean by a 'double clk pulse' but I'm assuming that 
you're feeding the 4MHz clock into 'something' in the FPGA that is clocked 
by 50 MHz.  If that's the case, then what you need to verify in the final 
technology map that the 4MHz signal comes into exactly one flip flop and the 
output of that exactly one flip flop is what you use to clock anything 
else...and to mitigate metastability a bit more, that 'anything else' logic 
might consist of again exactly one flop, the output of which is fed into the 
real logic (i.e. you're constucting a two flop synchronizer).  You'll also 
want to add synthesis attributes to any of these synchronizing flops to 
insure that the logic doesn't get opotomized in a way that ends up 
replicating the flops.  In any case, verify the final routed result brings 
4MHz into exactly one flop (and if adding a second sync flop that it too is 
the only load on the flop that captures the 4MHz)

4MHz -----> Flop -----> Flop -----> Logic that uses the '4MHz' input
Pin

Since you haven't stated just how you're using the 4MHz clock inside the 
FPGA, you should probably clarify that, but a failure rate every 0.2 seconds 
(10 M of the 50MHz clock) then it's quite apparent that one of the most 
likely causes of the failure is one of the following:
- Simple timing (whch will be fixed by what I outline in the previous 
paragraph).
- Signal quality
    1. Measured at the FPGA, are the rising and falling edges of the 50 MHz 
monotonic?
    2. Measured at the FPGA, the 4 MHz clock doesn't have to be absolutely 
monotonic since it doesn't appear to be used to sample anything, but if it 
dips and comes back up and the dip is low enough to appear to be a logic low 
than the 50 MHz could (and eventually will) sample it at precisely that bad 
point.
- Could be power as well, not dipping out of spec at the FPGA are you?

> unfortunatly the 4mhz clock needs to be used inside without phase
> delay, so oversampling and filtering with 50mhz is not an option,
> unless using very clever no delay glitch surpression filter
>
Might want to elaborate on the reason for the 'without phase delay' 
requirement, but assuming that to be the case then a different solution that 
would minimize the phase delay would be to feed the 4MHz into an onchip PLL 
(if you have one) to create a 48 MHz and use that instead of the 50 MHz. 
That way, the two clocks would maintain a fairly accurate phase relationship 
to one another thus avoiding violation of setup/hold time windows.

If the reason for 'without phase delay' requirement is because of other FPGA 
inputs that are synchronized to the 4MHz, then another solution might simply 
be a dual clock fifo to move those inputs from the 4MHz to the 50 MHz clock 
domain.

> external small R/C circuit on 5mhz doesnt change the error rate much,
> ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to
> give better results as using the 4mhz clock directly
>

This sounds like you are using the 4MHz to drive logic...big mistake (see 
first paragraph for the solution).

> any ideas how to really clean the 4mhz clock?

Unless you've scoped the 4MHz clock, why do you think it's not 'clean'?

> or any thumb guess what is the likeliness to see double clk edges when
> sampling 4mhz with async 50mhz?

Violating timing, inadequate power at the point of use and signal 
quality....when it comes right down to it those are the ONLY reasons.  In 
the end, that's what you'll find here as well.

> could the "error rate" of such sampling be that 1:10M what I am
> seeing?
>

Sure, it simply depends on precisely what the setup/hold timing window of 
the actual part is.  If you have freeze spray, a hot air gun and a simple 
way to quickly get your error rate measurement then try hitting your FPGA 
with the hot, measure your error rate (repeat with the cold) and see if it 
has a temperature dependency.  If it clearly does, then you have a timing 
problem (see first paragraph for the solution), if it doesn't or is not 
clearly temp dependent, then you likely have a power problem.  Based on the 
bits of info you've provided, I'm leaning towards the timing.   This is 
simply science experiment stuff and is not needed to engineer the solution, 
for that you need static timing analysis, proper clock domain crossing 
design technique and proper power supply distribution.

> I assume the 4 mhz clock is rather good, it coming from an ASIC and
> has total wire lenght from asic to FPGA maybe 20 mm (but over PCB edge
> connector). I did kinda think its hard to belive that the clock edge
> is so slow or noisy that 50mhz sampling could ever see double/wrong
> edges but guess i am wrong
>

No need to guess or speculate, unless you don't have a scope to simply 
measure.

> it doesnt seem to be cross talk either, as there arent much IOs
> toggling at all
>
> hm it looks like in rare cases the error is also one clock pulse
> missing!
>

Timing problems produce those symptoms as well.

> :) any good suggestions are welcome, how to troubleshoot the issue
>

Hopefully you'll find the above useful....to reiterate though, I can dang 
near guarantee the fundamental reason for the failure will be
- Violating setup/hold time in the 50 MHz clock
- Signal quality (50 MHz or 4 MHz)
- Power

What you need to do is measurement or analysis to either eliminate causes or 
turn up the design error.

> unfortunatly the FPGA is actel so can use any on-chip logic analyzer
> core, and the chip is rather full also, some internal signal could be
> routed out to external logic analyzer though if badly needed, but so
> far i am trying to fix the issue by thinking, and error-retry...
>

You shouldn't need to bring out anything, static timing analysis and a scope 
will get you to the root cause.

Good luck.

Kevin Jennings 

On Mar 29, 2:41=A0am, Antti <Antti.Luk...@googlemail.com> wrote:
> Hi
>
> FPGA has
> 1) 50mhz system clock from ext oscillator
> 2) 4Mhz clk that is async to the 50mhz
>
> problem, the 4MHz clk input sees double clk pulse, error rate
> approximate 1 to 10.000.000
> unfortunatly the 4mhz clock needs to be used inside without phase
> delay, so oversampling and filtering with 50mhz is not an option,
> unless using very clever no delay glitch surpression filter
>
> external small R/C circuit on 5mhz doesnt change the error rate much,
> ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to
> give better results as using the 4mhz clock directly
>
> any ideas how to really clean the 4mhz clock?
> or any thumb guess what is the likeliness to see double clk edges when
> sampling 4mhz with async 50mhz?
> could the "error rate" of such sampling be that 1:10M what I am
> seeing?
>
> I assume the 4 mhz clock is rather good, it coming from an ASIC and
> has total wire lenght from asic to FPGA maybe 20 mm (but over PCB edge
> connector). I did kinda think its hard to belive that the clock edge
> is so slow or noisy that 50mhz sampling could ever see double/wrong
> edges but guess i am wrong
>
> it doesnt seem to be cross talk either, as there arent much IOs
> toggling at all
>
> hm it looks like in rare cases the error is also one clock pulse
> missing!
>
> :) any good suggestions are welcome, how to troubleshoot the issue
>
> unfortunatly the FPGA is actel so can use any on-chip logic analyzer
> core, and the chip is rather full also, some internal signal could be
> routed out to external logic analyzer though if badly needed, but so
> far i am trying to fix the issue by thinking, and error-retry...
>
> Antti

Antti, click on

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

which shows two different ways to avoid the effect of double-edges on
a clock.
I wrote that many years ago, and published it in Xilinx XCell magazine
#34
Peter Alfke

On 29 Mrz., 16:41, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Antti" <Antti.Luk...@googlemail.com> wrote in message
>
> news:e6010199-ca1d-4540-8ae3-a69a3a23b106@b1g2000hsg.googlegroups.com...
>
> > Hi
>
> > FPGA has
> > 1) 50mhz system clock from ext oscillator
> > 2) 4Mhz clk that is async to the 50mhz
>
> > problem, the 4MHz clk input sees double clk pulse, error rate
> > approximate 1 to 10.000.000
>
> Not quite sure what you mean by a 'double clk pulse' but I'm assuming that
> you're feeding the 4MHz clock into 'something' in the FPGA that is clocked
> by 50 MHz.  If that's the case, then what you need to verify in the final
> technology map that the 4MHz signal comes into exactly one flip flop and the
> output of that exactly one flip flop is what you use to clock anything
> else...and to mitigate metastability a bit more, that 'anything else' logic
> might consist of again exactly one flop, the output of which is fed into the
> real logic (i.e. you're constucting a two flop synchronizer).  You'll also
> want to add synthesis attributes to any of these synchronizing flops to
> insure that the logic doesn't get opotomized in a way that ends up
> replicating the flops.  In any case, verify the final routed result brings
> 4MHz into exactly one flop (and if adding a second sync flop that it too is
> the only load on the flop that captures the 4MHz)
>
> 4MHz -----> Flop -----> Flop -----> Logic that uses the '4MHz' input
> Pin
>
> Since you haven't stated just how you're using the 4MHz clock inside the
> FPGA, you should probably clarify that, but a failure rate every 0.2 seconds
> (10 M of the 50MHz clock) then it's quite apparent that one of the most
> likely causes of the failure is one of the following:
> - Simple timing (whch will be fixed by what I outline in the previous
> paragraph).
> - Signal quality
>     1. Measured at the FPGA, are the rising and falling edges of the 50 MHz
> monotonic?
>     2. Measured at the FPGA, the 4 MHz clock doesn't have to be absolutely
> monotonic since it doesn't appear to be used to sample anything, but if it
> dips and comes back up and the dip is low enough to appear to be a logic low
> than the 50 MHz could (and eventually will) sample it at precisely that bad
> point.
> - Could be power as well, not dipping out of spec at the FPGA are you?
>
> > unfortunatly the 4mhz clock needs to be used inside without phase
> > delay, so oversampling and filtering with 50mhz is not an option,
> > unless using very clever no delay glitch surpression filter
>
> Might want to elaborate on the reason for the 'without phase delay'
> requirement, but assuming that to be the case then a different solution that
> would minimize the phase delay would be to feed the 4MHz into an onchip PLL
> (if you have one) to create a 48 MHz and use that instead of the 50 MHz.
> That way, the two clocks would maintain a fairly accurate phase relationship
> to one another thus avoiding violation of setup/hold time windows.
>
> If the reason for 'without phase delay' requirement is because of other FPGA
> inputs that are synchronized to the 4MHz, then another solution might simply
> be a dual clock fifo to move those inputs from the 4MHz to the 50 MHz clock
> domain.
>
> > external small R/C circuit on 5mhz doesnt change the error rate much,
> > ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to
> > give better results as using the 4mhz clock directly
>
> This sounds like you are using the 4MHz to drive logic...big mistake (see
> first paragraph for the solution).
>
> > any ideas how to really clean the 4mhz clock?
>
> Unless you've scoped the 4MHz clock, why do you think it's not 'clean'?
>
> > or any thumb guess what is the likeliness to see double clk edges when
> > sampling 4mhz with async 50mhz?
>
> Violating timing, inadequate power at the point of use and signal
> quality....when it comes right down to it those are the ONLY reasons.  In
> the end, that's what you'll find here as well.
>
> > could the "error rate" of such sampling be that 1:10M what I am
> > seeing?
>
> Sure, it simply depends on precisely what the setup/hold timing window of
> the actual part is.  If you have freeze spray, a hot air gun and a simple
> way to quickly get your error rate measurement then try hitting your FPGA
> with the hot, measure your error rate (repeat with the cold) and see if it
> has a temperature dependency.  If it clearly does, then you have a timing
> problem (see first paragraph for the solution), if it doesn't or is not
> clearly temp dependent, then you likely have a power problem.  Based on the
> bits of info you've provided, I'm leaning towards the timing.   This is
> simply science experiment stuff and is not needed to engineer the solution,
> for that you need static timing analysis, proper clock domain crossing
> design technique and proper power supply distribution.
>
> > I assume the 4 mhz clock is rather good, it coming from an ASIC and
> > has total wire lenght from asic to FPGA maybe 20 mm (but over PCB edge
> > connector). I did kinda think its hard to belive that the clock edge
> > is so slow or noisy that 50mhz sampling could ever see double/wrong
> > edges but guess i am wrong
>
> No need to guess or speculate, unless you don't have a scope to simply
> measure.
>
> > it doesnt seem to be cross talk either, as there arent much IOs
> > toggling at all
>
> > hm it looks like in rare cases the error is also one clock pulse
> > missing!
>
> Timing problems produce those symptoms as well.
>
> > :) any good suggestions are welcome, how to troubleshoot the issue
>
> Hopefully you'll find the above useful....to reiterate though, I can dang
> near guarantee the fundamental reason for the failure will be
> - Violating setup/hold time in the 50 MHz clock
> - Signal quality (50 MHz or 4 MHz)
> - Power
>
> What you need to do is measurement or analysis to either eliminate causes or
> turn up the design error.
>
> > unfortunatly the FPGA is actel so can use any on-chip logic analyzer
> > core, and the chip is rather full also, some internal signal could be
> > routed out to external logic analyzer though if badly needed, but so
> > far i am trying to fix the issue by thinking, and error-retry...
>
> You shouldn't need to bring out anything, static timing analysis and a scope
> will get you to the root cause.
>
> Good luck.
>
> Kevin Jennings

Hi all and thanks for all suggestions!
some additional info

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

so what is failing is really simple circuit!
it also looks like when double pulses are seen the FPGA is not
changing any of its output so its no SSO noise

I could understand power supply noise to cause double pulses, but how
to explain the missing pulses?

I dont have scope here now, but i have tried to troubleshoot the clock
problem before and have looked the signals with scope without seeing
anything helpful to get to the problem, i will do it again if I dont
get it working this weekend

the timing analyze with actel FPGA is something so:so, I have seen a
shift register clocked at 4mhz working 100% when FPGA utilization
below 90% and failing 100% when FPGA utilization over 90%, without any
problem reported by the timing tools or post place simulation. I wasnt
belive my eyes when i did see that, but so it was. Later i found some
actel appnote about methods of dealing with such cases. I hoped that
actel tools take of such situations but they do not.

so I have little hope that some more detailed timing analyzes gives
the solution to the problem

at the moment the 4mhz strobe should have small internal delay so 2 FF
at 50mhz is already too much, so i need either deglitch with no phase
delay or then need change my other logic to tolerate the delay

I have some other options too, but all they are not so simple and easy
to implement, so I am hoping some magic hint to fix the problem :)
will try use the 4mhz directly and measure error rate, with 50mhz
running and disabled, as last resort i can use other free running
clock entering FPGA from different side and PLL, and disable the 50mhz
oscillator completly this should hopefully decrease the overall power
and crosstalk noise

Antti

On 29 Mrz., 18:00, Peter Alfke <al...@sbcglobal.net> wrote:
> On Mar 29, 2:41 am, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
> > Hi
>
> > FPGA has
> > 1) 50mhz system clock from ext oscillator
> > 2) 4Mhz clk that is async to the 50mhz
>
> > problem, the 4MHz clk input sees double clk pulse, error rate
> > approximate 1 to 10.000.000
> > unfortunatly the 4mhz clock needs to be used inside without phase
> > delay, so oversampling and filtering with 50mhz is not an option,
> > unless using very clever no delay glitch surpression filter
>
> > external small R/C circuit on 5mhz doesnt change the error rate much,
> > ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to
> > give better results as using the 4mhz clock directly
>
> > any ideas how to really clean the 4mhz clock?
> > or any thumb guess what is the likeliness to see double clk edges when
> > sampling 4mhz with async 50mhz?
> > could the "error rate" of such sampling be that 1:10M what I am
> > seeing?
>
> > I assume the 4 mhz clock is rather good, it coming from an ASIC and
> > has total wire lenght from asic to FPGA maybe 20 mm (but over PCB edge
> > connector). I did kinda think its hard to belive that the clock edge
> > is so slow or noisy that 50mhz sampling could ever see double/wrong
> > edges but guess i am wrong
>
> > it doesnt seem to be cross talk either, as there arent much IOs
> > toggling at all
>
> > hm it looks like in rare cases the error is also one clock pulse
> > missing!
>
> > :) any good suggestions are welcome, how to troubleshoot the issue
>
> > unfortunatly the FPGA is actel so can use any on-chip logic analyzer
> > core, and the chip is rather full also, some internal signal could be
> > routed out to external logic analyzer though if badly needed, but so
> > far i am trying to fix the issue by thinking, and error-retry...
>
> > Antti
>
> Antti, 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 many years ago, and published it in Xilinx XCell magazine
> #34
> Peter Alfke

Hi Peter,

thanks I do know those things think also but i still printed the xcell
pages out :)
now, in Xilinx FPGA I dont see the problem :)
but the final target is actel FPGA (because: cost+security+package)
and in Actel i see both double and missing clocks

so i am still puzzled, there must be something very basic bad thing
somewhere

Antti