Re: async clk input, clock glitches

On 29 Mrz., 20:27, "KJ" <kkjenni...@xxxxxxxxxxxxx> wrote:
"Antti" <Antti.Luk...@xxxxxxxxxxxxxx> wrote in message

news:92139727-cfa9-4b12-bf80-d63debe231a9@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



On 29 Mrz., 16:41, "KJ" <kkjenni...@xxxxxxxxxxxxx> wrote:
"Antti" <Antti.Luk...@xxxxxxxxxxxxxx> wrote in message

news:e6010199-ca1d-4540-8ae3-a69a3a23b106@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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

OK, so it appears that the 4 MHz input is being synchronized to the 50 MHz
clock through a single flip flop, but have you verified that the final
routed design uses only one flip flop?

Are you using the now synchronized 4 MHz signal as a clock? Do you know for
sure that the Actel device will properly generate an internal clock signal
from the output of a flip flop? You can't see clock signal quality internal
to a device but that doesn't imply that it doesn't matter. If "output of a
flip flop to the clock input of another" is not something that Actel handle
then maybe you shouldn't be doing that.

the asic clock is know to be perfect many other devices can receive it
and have 0 error rate (have not seen error ever!)

That's good to know.

the 50mhz clock signal quality, well it doesn matter, as whatever
could be wrong, it could not explain the double and missing pulse
counts ?

Signal quality on the 50 MHz clock does matter...what if the osc is bad or
flaky? It's not my first suspect either but again worth verifying at the
input to the FPGA with a scope (when you get access to one) so that it can
be eliminated as a cause.

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

That would also tend to lower power supply noise as a culprit too in my
mind...again, it can only be eliminated as a cause by verification with a
scope when you get a chance.

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

Bad power is worse than a bad clock, all sorts of bad things can happen.

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

From here it really smells like the problem is not properly synchronizing
the 4 MHz signal or that the internally generated clock is not a good clock
for whatever reason.

Also, is the output of the two bit counter directly observable to you and is
that the reason you say that you miss a clock or get two every now and then
or is it because of some other downstream logic output? The reason for
asking is because no matter what you do, if you use the 'synchronized 4 MHz'
to actually clock a flip flop the output of that two bit counter will be
skewed a bit from the 50 MHz clock because of the unavoidable clock to
output delay of the flip flop (plus possible additional skew from
differences in the clock distribution between the 50 MHz and the
'synchronized 4 MHz' internal to the device.

I've found and fixed many other designer's errors by getting rid of
internally generated clocks because, no matter how well you ...

Erfahren Sie mehr »

Hi Kevin,

many thanks for all the detailed help!

this morning I was pretty sure i have the correct answer to the
problem - VCCINT bypass capacitor(s)
but big disappointment, adding then (<=1.5mm from package) did not
change the error rate at all !! :(

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

the 4Mhz clock is really not a clock, its byte write strobe from
external host

most of the FPGA logic can/should be clocked with this strobe, and i
see little reasons to move all that logic into 50mhz clock domain

in 50mhz domains 2 modules exist, one of them is working fully on the
"other side" of dual port RAM, and the other module is also not
causing problems, it generates 8 clocks per strobe, and shifts in a
byte

my 2 bit counter is not directly observable, i have software access to
return data addressed with the counter so I have test software that
compares the returned to data to known good response and calculates
the error types, either missing or extra strobe and displays the error
counts and count of good responses

ah, the 4 mhz strobe/clk is routed as global clock, I do insert the
global buffer primitives by hand and verify that the are implemented
by the tools as well.

if any FF is clocked by local routing in Actel FPGA then it is
complete disaster

Antti
.

Relevant Pages

  • Re: Antii, can you give us an update?
    ... register connected to the input mux of the LFSR load input ... clock domains; with purely combinational logic ... work 100% when FPGA is almost empty (no matter what signal drivers ... but the LFSR enable/load signals do not share any logic with any of ...
    (comp.arch.fpga)
  • Re: 64 bit division compensate NCO
    ... get a new delta phase value for the NCO sounds more like a LOW fidelity ... your clocks are in the range of 1 GHz (and that your fpga can handle clocks ... decreasing clock frequencies. ...
    (comp.arch.fpga)
  • Re: Antii, can you give us an update?
    ... that load the load enable signal is FULLY DISABLED ... register connected to the input mux of the LFSR load input ... clock domains; with purely combinational logic ... work 100% when FPGA is almost empty (no matter what signal drivers ...
    (comp.arch.fpga)
  • Re: rs232 uart: testbench vs real world, and the missing first letter.
    ... inside the FPGA to do the slow procedural/sequential stuff? ... up to 120MHz clock speed in my Spartan-3. ...   -- let VHDL do the work of computing the divisor! ... I didn't even know what an FFT was ...
    (comp.arch.fpga)
  • Spartan 3 clock to output tristate timing
    ... I've got a problem at work where the FPGA group is at war with the ... designed the board although there was not a lot of original design. ... proper bus timing analysis and I need the data on the FPGA. ... rather than the other clock being provided to the FPGA. ...
    (comp.arch.fpga)