async clk input, clock glitches

al

d o o e c .

ee

n

In

of

le

GA

ng

e

ng

es

or

al

a e k

is

n

z'

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 (

inal

and

g

nto

to

too

the

st

50

if

gic

at

?

on

ip

Hz.

er

h,

(see

'?

hen

In

w of

mple

FPGA

if

ming

ot

on

is

g

dge

e y

dang

uses

r

be

o a

Hz

for

al

rnal

f a

dle

or

e

an

a g

ock

d is

hen

MHz'

Hi all

the FPGA resource % wasnt the thing after further reducing the utilization down to 37% the error rate increased and missing pulses re- apperared! but, when then removing the flop from 4mhz strobe AND changing synplify constraints:

45 minutes up and running no error detected so far pulse count >10G

sure I need the design to work without error with FPGA utilization

indicator that there is really nothing wrong with the 4mhz strobe signal, so no external conditioning required

Antti

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 (

g

to

st

50

if

at

?

on

ip

er

h,

'?

w

if

ot

on

is

g e y r

be

o a

Hz

al

f

or

e

an

a g d n

there is no asic clock coming only

select active low and strobe(clk) idle high pulses low, write latch on rising edge

and the strobe IS CLEAN no glitch pure signal tested verified...

after applying the changes that made 0 error for 37% full FPGA to the full desing (82% full) the resulting design, well still has 0 clock error but the remaining portions of the design are no longer working..

so i need some more work to get the full design working properly

Antti

No, I understand you do not have the clock - just saying that you SHOULD have the clock. The interface seems, at best, very flakey to me. If the strobe was clean you would have zero problems. The system should be 'right by design' and not have work arounds applied to cover up a problem.

Antti schrieb:

[lot of text removed]

Offtopic, but IMHO necessary.

And this goes to many other posters in this NG.

No offence. Falk

Dear Falk,

really? unfortunatly i am using google groups so it sometimes hiding the quoted when replying, i had the feeling also that something is not perfect with the post, but was in hurry. sorry that it made you feel that you need to play the teacher guy.

Antti

[snip]

similar design WORKS in Xilinx FPGA always no workarounds needed.

the actel version is optimized for actel fabric, what forced the use of global clock lines for some none clock nets, and other changes that reduced the logic utilization for Actel target architecture.

the interface is not mine, and it is not flakey, it works and it works reliable and i can not change it. right now it also work in my FPGA with 82% percent full been working over 6 hours continuous testing, 0 errors.

but with 82% full some of the other logic that worked, stopped working. so i need keep cleaning up the design and doing more and more iterations, when I remove the global buffers from non global signal the design would not fit the target device (actel generates 2 logic per many flip flops), my current design still has 22 flip flops mapped to 2 logic cells, and 23 flops mapped to 4 logic cell per flop, so wastin 91 logic cells or 8% of the total resources. I can try to run some more rounds of manual logic optimization, but this is not really a funny job. but using larger FPGA or FPGA from other vendor would increase the BOM cost for at least 1 usd more likely for

2 usd what is unacceptable for the design, so i need optimize and optimize and the fight actel tools and weirdness.

I know very well that: "any digital design works AS DESIGNED" first attempt if it is done "correctly". It really does, but sometimes the way to it isnt so easy.

so, the strobe is clean, 100% verfied, but there are cases where it appears to have problems in actel FPGA.

Antti to Xilinx I would have saved many month of deep troubleshooting, would Xilinx had required package options for S3AN.. but now it was just another design loss for Xilinx. Maybe S4 will re-introduce small packages who know but for this project its too late anyway.

Let's be blunt, any signal that you use "rising_edge(xxx)", "falling_edge(xxx)", "xxx'event and xxx = '1'", "xxx'event and xxx='0' and all the other variants thereof are edge sensitive signals, whether it is a free running 'clock' is irrelevant.

So then why did you (from an earlier post) bring this strobe into a flip flop that is clocked by the 50 MHz clock? You've created a new signal internal to the device that you can't observe and will be violating setup/hold timing by design which means that this signal will be metastable at some times and you're using edges of it internally....it's highly unlikely now that that internal signal is nice and monotonic...that's why you're seeing the flaky operation.

If you intend to use the 4MHz clock/strobe/whatever to sample things inside the FPGA, then don't muck with it, use it directly as you would use the 50 MHz osc clock and don't insert any logic/flops/anything in the path.

The reason is that the two clock domains almost inevitably will need to communicate with one another. That communication will be cross clock domains, it is 'usually' simpler to synchronize up front and then clock everything with one clock. The simple answer to the 'reason to move...' is to avoid the type of timing grief that you're experiencing. Then again, experience something for yourself is almost always the best teacher.

Having to do gyrations with tools to get it to 'work', generally only results in things that work on certain boards, or start failing at different temperatures and other odd things. The reason is that the fundamental design issue has not been addressed, band aids have only been added to address symptoms seen on a limited set of boards.

Fundamentally, you need to decide

1. If you want to have things running around internally in the FPGA in two different clock domains and use proper handshaking/dual clock fifo techniques everyplace signals from the two come together.
2. Synchronize the 4MHz to the 50 MHz up front and then run everything in the FPGA at 50 MHz and have only one clock domain.

Either approach is viable, #1 will take more effort on your part to get working. Whether the payoff is worth it to you or not is a decision that only you can make.

I think I said basically the same thing previously about having to fix many other designer's designs by getting rid of internally generated clocks. By the way, that type of design issue is not unique to Actel.

Kevin Jennings

More likely, it's his use of a flip flop output which goes metastable as a clock input to another flop.

New routes produce differences in actual device timing which precludes one from making any judgments about 'cross-talk sensitivity' based on changes in failure rates....

Crosstalk happens, but is usually pretty far down on the checklist of actual causes for design failure....after timing, clock domain crossing (which is really timing as well), signal quality and power.

KJ

Jim

look as example figure 9 there how do you like if your FPGA vendor suggest using this type of clock distribution?

i do not have any local clocks, not any more, but i have seen those effects very well. I assumed the FGPA fitter tools to take care those situations or issue warning at least or that it shows in post place simulation, but no. those Actel FF that clock 100% false can pass fitter and show no problems in post-place sims also.

my failure rate change may also be just different fitter run differences. I have no almost all working, that is no double or missing strobes, and the 50mhz domain part also working ok

Antti

The usefulness of the trigger from an engineering perspective is to turn a slow edge into a faster one in order to meet input characteristics of a part that can not tolerate the slower edge. Use of a schmitt trigger to address any of the issues that you mention would only be considered if there are some other physical constraints that precludes the proper engineering solution which would consist of

- Termination

- Proper grounding

- Differential signalling

for the simple reason that the trigger would not be addressing the root cause issues that you brought up.

KJ

So now everything is clocked by the 50 MHz clock then? Nothing by the 4 MHz strobe (or anything derived from it)?

It would show up when doing static timing analysis under fastest conditions (i.e. when analyzing for minimum delays, Tco, etc.) and where analysis between clock domains is enabled.

Post-place sims do not catch timing errors, they do not catch metastability problems. Generally they just take a long time to run.

Congrats....now try the freeze spray and the hot air gun to make sure that you're not sensitive to temperature

KJ

So the 'key' trigger condition is using local routing for clock ?

No, but these tests are to see if there is a CHANGE in failure rate, as any change indicates a 'cross-talk sensistivity' - and you do see significant changes in error rates :)

What did changing the constraints do ?

Do you know if this is a time-domain problem (Tsu/Th) or a crosstalk problem ? (device fabric not good enough for clocks) or models not matching loading/skew effects in real device (and being not as well tested, has been mised by Actel?)

Did someone else find this issue with local clocks == dodgy - ISTR an earlier thread ?

-jg

Kevin

in actel FPGA following is possible:

design including "one sincle clock 4mhz clocking a 32 bit wide shift register" all signals are perfect as signal quality

now while this ALWAYS works when the rest of the FPGA is empy, it may also ALWAYS fail, if the rest of the FPGA is full (if the clock uses local routing).

now if the routing delay and internal skew in FPGA cause place-and- route result that NEVER works, see actel appnote, then this delay SHOULD be known for the FPGA tools, and it should also in post-place simulations IMHO.

so there should a way that tools report, hey your shift register clocked at 4mhz will not work! while it is ok, that local clk routing messes everything up, the tools should be able to report those errors, what they at least in some cases do not.

maybe I am dumb. but that case as described above exist.

Antti

And you've verified that the timing analysis report indicates that all of the following analysis was performed with no timing violations?

- Slow model (i.e. 'slow' part, prop delays at their slowest)

- Fast model (i.e. 'slow' part, prop delays at their slowest)

- Analysis between clock domains is being performed

If that is not the case, then you're not getting the full picture from the static timing analysis and need to re-run the analysis.

Simulation can put things at 'fast', 'slow', (maybe 'typical') but it does those things for all signals in the same manner which may not reflect what the actual part is doing. Simulation has no way of saying that signal1 will switch somewhere between this time and that time and signal2 will switch between two other times so compute when the full min/max time range where some signal that uses signals 1 and 2 will change within a single run. That is why static timing analysis is the tool that needs to be used, it does exactly that.

Besides, the simulation was (I'm assuming) reporting that your strobe signal was violating setup/hold time relative to the 50 MHz clock when you had it come into a flop clocked by the 50 MHz osc as you described in an earlier post. Presumably you were ignoring that message because it was convenient to do so and didn't consider what the ramifications of that could be (i.e. producing a metastable output signal that you use to clock other flops).

Not dumb, but maybe not understanding fully how to perform static timing analysis.

Kevin Jennings

In previous post...

- Fast model (i.e. 'fast' part, prop delays at their fastst)

KJ

Schmit trigger will not help you. Please try to register all inputs, verify the FFs are in the IOB pads, and your troubles will go. It is very easy to understand the missing clock pulses: your 4mhz signal used as strobe controls many FFs in your design. But actually, you do not control the timing propagation of the combinatorial logic from the pad to these FFs. When a rising of 50mhz is very close to the rising_edge 4mhz, some FFs see the 4Mhz signal as a 0 logic level and some others see the 4 Mhz signal as a 1 logic level... and YOU LOSE SOME EDGE ON SOME FFs

Very common error !

Laurent

Larry, there error happened when 1 single FF was clocked with 50mhz and having 4mhz pulses in D.

the output from this FF did miss one COMPLETE pulse (one rising edge) in about 1 per 100M pulses counted.

that can only happen if the pulse was not latched proper level for many clocks of 50mhz, something i can really not understand.

well all those errors have disappeared happily, without schmit trigger or any other magic

Antti