async clk input, clock glitches

Antti wrote:
<paste>
> if any FF is clocked by local routing in Actel FPGA then it is
> complete disaster

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

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

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

> but, when then removing the flop from 4mhz strobe AND changing
> synplify constraints:

What did changing the constraints do ?

> 
> 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
> 
>>=90% but seeing the PCB to not fail on the strobe is already some
> indicator that there is really nothing wrong with the 4mhz strobe
> signal, so no external conditioning required

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

"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message 
news:47efdf2b@clear.net.nz...
> Antti wrote:
> <paste>
>> if any FF is clocked by local routing in Actel FPGA then it is
>> complete disaster
>
> So the 'key' trigger condition is using local routing for clock ?
>

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

>> the FPGA resource % wasnt the thing after further reducing the
>> utilization down to 37% the error rate increased and missing pulses re-
>> apperared!
>
> 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 :)
>

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 

On 30 Mrz., 21:42, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Antti wrote:
>
> <paste>
>
> > if any FF is clocked by local routing in Actel FPGA then it is
> > complete disaster
>
> So the 'key' trigger condition is using local routing for clock ?
>
> > 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!
>
> 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 :)
>
> > but, when then removing the flop from 4mhz strobe AND changing
> > synplify constraints:
>
> What did changing the constraints do ?
>
>
>
> > 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
>
> >>=90% but seeing the PCB to not fail on the strobe is already some
> > indicator that there is really nothing wrong with the 4mhz strobe
> > signal, so no external conditioning required
>
> 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

Jim

http://www.actel.com/documents/Clock_Skew_AN.pdf

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

"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message 
news:47eebe69@clear.net.nz...
> KJ wrote:
>>
>> Your post never mentioned anything about having measured a slow edge on 
>> the 4MHz signal either.  If the edge rate is within spec, adding a 
>> Schmitt trigger will have no effect.
>
> Not entirely true.
> In the real analog world, there are other details that can
> trip you up. Ground level shifting and series inductances all
> conspire against clean digital operation...
>
> (The best schmitt is a non-inverting one.)
>

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 

"Antti" <Antti.Lukats@googlemail.com> wrote in message 
news:368339ad-6636-4a63-a57e-9785bc3ac581@m36g2000hse.googlegroups.com...
> On 30 Mrz., 21:42, Jim Granville <no.s...@designtools.maps.co.nz>
>
> http://www.actel.com/documents/Clock_Skew_AN.pdf
>
> 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.

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

> I assumed the FGPA fitter tools to take care those
> situations or issue warning

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.

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

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

> 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
>
Congrats....now try the freeze spray and the hot air gun to make sure that 
you're not sensitive to temperature

KJ 

> Post-place sims do not catch timing errors, they do not catch metastability
> problems.  Generally they just take a long time to run.
>
> > 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
>
> Congrats....now try the freeze spray and the hot air gun to make sure that
> you're not sensitive to temperature
>
> KJ

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

"Antti" <Antti.Lukats@googlemail.com> wrote in message 
news:b36154f4-2769-4630-9d56-e5af9224046a@c26g2000prf.googlegroups.com...
>> Post-place sims do not catch timing errors, they do not catch 
>> metastability
>> problems.  Generally they just take a long time to run.
>>
>> > 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
>>
>> Congrats....now try the freeze spray and the hot air gun to make sure 
>> that
>> you're not sensitive to temperature
>>
>> KJ
>
> 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 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.

> and it should also in post-place
> simulations IMHO.
>

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

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

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 

On Mar 29, 9:59 pm, Antti <Antti.Luk...@googlemail.com> wrote:
> On 29 Mrz., 20:34, Mike Treseler <mike_trese...@comcast.net> wrote:
>
> > Antti wrote:
> > > any ideas how to really clean the 4mhz clock?
>
> > I would try soldering on one of those
> > little schmitt trigger packs. Sometimes
> > a low slew rate will clock both edges
> > once in a while.
>
> >           -- Mike Treseler
>
> yes schmit trigger input could be the cure..
> but i still cant understand the missing clock pulses!
>
> Antti

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
www.amontec.com

On 30 Mrz., 22:42, j...@amontec.com wrote:
> On Mar 29, 9:59 pm, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
> > On 29 Mrz., 20:34, Mike Treseler <mike_trese...@comcast.net> wrote:
>
> > > Antti wrote:
> > > > any ideas how to really clean the 4mhz clock?
>
> > > I would try soldering on one of those
> > > little schmitt trigger packs. Sometimes
> > > a low slew rate will clock both edges
> > > once in a while.
>
> > >           -- Mike Treseler
>
> > yes schmit trigger input could be the cure..
> > but i still cant understand the missing clock pulses!
>
> > Antti
>
> 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 !
>
> Laurentwww.amontec.com

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