Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 130675

Article: 130675
Subject: Re: async clk input, clock glitches
From: Antti <Antti.Lukats@googlemail.com>
Date: Sun, 30 Mar 2008 01:50:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 29 Mrz., 20:27, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Antti" <Antti.Luk...@googlemail.com> wrote in message
>
> news:92139727-cfa9-4b12-bf80-d63debe231a9@y24g2000hsd.googlegroups.com...
>
>
>
> > 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 fin=
al
> >> technology map that the 4MHz signal comes into exactly one flip flop an=
d
> >> 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 int=
o
> >> 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 to=
o
> >> 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 th=
e
> >> 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 logi=
c
> >> 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 (s=
ee
> >> 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 whe=
n
> >> > 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 simp=
le
> >> way to quickly get your error rate measurement then try hitting your FP=
GA
> >> 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 timi=
ng
> >> 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 edg=
e
> >> > 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 da=
ng
> >> 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 caus=
es
> >> 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 f=
or
> 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 intern=
al
> 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 handl=
e
> 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 cloc=
k
> 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 the=
n
> 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 MH=
z'
> 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 =BB

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 (<=3D1.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

Article: 130676
Subject: Re: async clk input, clock glitches
From: Antti <Antti.Lukats@googlemail.com>
Date: Sun, 30 Mar 2008 03:16:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 30 Mrz., 10:50, Antti <Antti.Luk...@googlemail.com> wrote:
> On 29 Mrz., 20:27, "KJ" <kkjenni...@sbcglobal.net> wrote:
>
> > "Antti" <Antti.Luk...@googlemail.com> wrote in message
>
> >news:92139727-cfa9-4b12-bf80-d63debe231a9@y24g2000hsd.googlegroups.com...=

>
> > > 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 f=
inal
> > >> 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 anythin=
g
> > >> 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 i=
nto
> > >> 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 mo=
st
> > >> 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 lo=
gic
> > >> low
> > >> than the 50 MHz could (and eventually will) sample it at precisely th=
at
> > >> 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 soluti=
on
> > >> that
> > >> would minimize the phase delay would be to feed the 4MHz into an onch=
ip
> > >> PLL
> > >> (if you have one) to create a 48 MHz and use that instead of the 50 M=
Hz.
> > >> 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 oth=
er
> > >> 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 muc=
h,
> > >> > 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 w=
hen
> > >> > 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 windo=
w of
> > >> the actual part is.  If you have freeze spray, a hot air gun and a si=
mple
> > >> 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 ti=
ming
> > >> problem (see first paragraph for the solution), if it doesn't or is n=
ot
> > >> 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 crossin=
g
> > >> 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 e=
dge
> > >> > connector). I did kinda think its hard to belive that the clock edg=
e
> > >> > 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 simpl=
y
> > >> 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 ca=
uses
> > >> or
> > >> turn up the design error.
>
> > >> > unfortunatly the FPGA is actel so can use any on-chip logic analyze=
r
> > >> > core, and the chip is rather full also, some internal signal could =
be
> > >> > routed out to external logic analyzer though if badly needed, but s=
o
> > >> > 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 M=
Hz
> > 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 sign=
al
> > from the output of a flip flop?  You can't see clock signal quality inte=
rnal
> > to a device but that doesn't imply that it doesn't matter.  If "output o=
f a
> > flip flop to the clock input of another" is not something that Actel han=
dle
> > 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 th=
e
> > input to the FPGA with a scope (when you get access to one) so that it c=
an
> > 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 synchronizin=
g
> > the 4 MHz signal or that the internally generated clock is not a good cl=
ock
> > for whatever reason.
>
> > Also, is the output of the two bit counter directly observable to you an=
d is
> > that the reason you say that you miss a clock or get two every now and t=
hen
> > 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
>
> ...
>
> Erfahren Sie mehr =BB

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
>=3D90% 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

Antti

Article: 130677
Subject: Re: async clk input, clock glitches
From: "Icky Thwacket" <it@it.it>
Date: Sun, 30 Mar 2008 11:42:34 +0100
Links: << >>  << T >>  << A >>

"Antti" <Antti.Lukats@googlemail.com> wrote in message 
news:0139131e-741b-438b-bfb4-580a19213014@e39g2000hsf.googlegroups.com...
On 29 Mrz., 20:27, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Antti" <Antti.Luk...@googlemail.com> wrote in message
>
> news:92139727-cfa9-4b12-bf80-d63debe231a9@y24g2000hsd.googlegroups.com...
>
>
>
> > 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
>
> 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


++++++++++++

I think you may have stated your problem!

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

The strobe may be just a loose decode internal to the ASIC and may well 
glitch. A strobe should be used as an enabling signal - to 'strobe' data in 
to the FPGA you should use a clock enabled D type, with the ASIC clock to 
clock, the 'strobe' to enable, and data in.




Article: 130678
Subject: Re: async clk input, clock glitches
From: Antti <Antti.Lukats@googlemail.com>
Date: Sun, 30 Mar 2008 03:56:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 30 Mrz., 12:42, "Icky Thwacket" <i...@it.it> wrote:
> "Antti" <Antti.Luk...@googlemail.com> wrote in message
>
> news:0139131e-741b-438b-bfb4-580a19213014@e39g2000hsf.googlegroups.com...
> On 29 Mrz., 20:27, "KJ" <kkjenni...@sbcglobal.net> wrote:
>
> > "Antti" <Antti.Luk...@googlemail.com> wrote in message
>
> >news:92139727-cfa9-4b12-bf80-d63debe231a9@y24g2000hsd.googlegroups.com...=

>
> > > 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 anythin=
g
> > >> 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 mo=
st
> > >> 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 th=
at
> > >> 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 soluti=
on
> > >> that
> > >> would minimize the phase delay would be to feed the 4MHz into an onch=
ip
> > >> 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 oth=
er
> > >> 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 muc=
h,
> > >> > 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 windo=
w
> > >> 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 n=
ot
> > >> 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 crossin=
g
> > >> 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 edg=
e
> > >> > 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 simpl=
y
> > >> 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 analyze=
r
> > >> > core, and the chip is rather full also, some internal signal could =
be
> > >> > routed out to external logic analyzer though if badly needed, but s=
o
> > >> > 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 M=
Hz
> > 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 sign=
al
> > 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 o=
f
> > 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 th=
e
> > input to the FPGA with a scope (when you get access to one) so that it c=
an
> > 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 synchronizin=
g
> > 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 an=
d
> > 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 =BB
>
> 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 (<=3D1.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
>
> ++++++++++++
>
> I think you may have stated your problem!
>
> "the 4Mhz clock is really not a clock, its byte write strobe from
> external host"
>
> The strobe may be just a loose decode internal to the ASIC and may well
> glitch. A strobe should be used as an enabling signal - to 'strobe' data i=
n
> to the FPGA you should use a clock enabled D type, with the ASIC clock to
> clock, the 'strobe' to enable, and data in.

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


Article: 130679
Subject: Re: async clk input, clock glitches
From: "Icky Thwacket" <it@it.it>
Date: Sun, 30 Mar 2008 12:25:52 +0100
Links: << >>  << T >>  << A >>

"Antti" <Antti.Lukats@googlemail.com> wrote in message 
news:731e01b9-cf36-47e0-aa73-b4bb693eb571@e67g2000hsa.googlegroups.com...
On 30 Mrz., 12:42, "Icky Thwacket" <i...@it.it> wrote:
> "Antti" <Antti.Luk...@googlemail.com> wrote in message
>
> news:0139131e-741b-438b-bfb4-580a19213014@e39g2000hsf.googlegroups.com...
> On 29 Mrz., 20:27, "KJ" <kkjenni...@sbcglobal.net> wrote:
>
> > "Antti" <Antti.Luk...@googlemail.com> wrote in message
>
> >news:92139727-cfa9-4b12-bf80-d63debe231a9@y24g2000hsd.googlegroups.com...
>
> > > 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
>
> > 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
>
> ++++++++++++
>
> I think you may have stated your problem!
>
> "the 4Mhz clock is really not a clock, its byte write strobe from
> external host"
>
> The strobe may be just a loose decode internal to the ASIC and may well
> glitch. A strobe should be used as an enabling signal - to 'strobe' data 
> in
> to the FPGA you should use a clock enabled D type, with the ASIC clock to
> clock, the 'strobe' to enable, and data in.

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





Article: 130680
Subject: After reset, the PC register of PPC is not back to 0Xfffffffc
From: louis <yilu@ce.et.tudelft.nl>
Date: Sun, 30 Mar 2008 06:15:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi, All,

I built a PowerPC system on Xilinx ML410 board (Virtex4 fx60), the
system contains 64K OCM instruction memory and 64K PLB data memory. I
used XMD to debug the system via the jtagppc, when I reset the system,
the PC register went back to a address like "0Xfffff048". But
according to the PPC manual, after reset, the PC should be
"0Xfffffffc". Does anyone met the similar problem before?

regards,
louis

Article: 130681
Subject: Re: async clk input, clock glitches
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Sun, 30 Mar 2008 16:08:55 +0200
Links: << >>  << T >>  << A >>
Antti schrieb:

[lot of text removed]

> there is no asic clock coming
> only

Offtopic, but IMHO necessary.

http://www.netmeister.org/news/learn2quote.html

And this goes to many other posters in this NG.

No offence.
Falk

Article: 130682
Subject: Synthesisable Timer in VHDL
From: move <liubenyuan@gmail.com>
Date: Sun, 30 Mar 2008 07:41:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
hi all:

i am currently working on a "toy" design of my first big project (in
VHDL) on the Xilinx Spartan III starter kit. now facing a timer
problem and i could not properlly solve it using my limited design
experience, here is it:

module A will prepare data for output (node : dout(7 downto 0)) to
module B when it receive a READY signal from B. in order to notify B
that the data is ready on the bus , A will ouput a signal DONE , but
the DONE will be '1' after 30 ms A received signal READY and will just
last 10 ms before going low. I wonder is there any standard or elegant
way of implement the timer in VHDL?

PLZ give me some hint!
thank U all in advance ! :)

Article: 130683
Subject: Re: async clk input, clock glitches
From: Antti <Antti.Lukats@googlemail.com>
Date: Sun, 30 Mar 2008 08:18:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 30 Mrz., 16:08, Falk Brunner <Falk.Brun...@gmx.de> wrote:
> Antti schrieb:
>
> [lot of text removed]
>
> > there is no asic clock coming
> > only
>
> Offtopic, but IMHO necessary.
>
> http://www.netmeister.org/news/learn2quote.html
>
> 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






Article: 130684
Subject: Re: async clk input, clock glitches
From: Antti <Antti.Lukats@googlemail.com>
Date: Sun, 30 Mar 2008 08:30:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
[snip]
> >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.

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.






Article: 130685
Subject: System Generator Error
From: anilcelebi <anilcelebi@gmail.com>
Date: Sun, 30 Mar 2008 08:45:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I am trying to generate the ise project files from the system
generator token in simulink but i am getting the following error.

--------------------------------------------------------------------------------
Summary of Errors:
Error 0001: caught standard exception
     Block: Unspecified
--------------------------------------------------------------------------------

Error 0001:

Reported by:
  Unspecified

Details:
standard exception: XNetlistEngine:
An exception was raised:
com.xilinx.sysgen.netlist.NetlistInternal: couldn't write
C:\XUP\Workshops\advanced_dsp_flow\labs\lab1\xupv2p\xupv2pro\sysgen
\ngc_verilog_QS2P\coregen_1zCO/coregen_tmp/distributed_arithmetic_f?
r_filter_virtex_9_0_abceec866b698a15.coe
at C:/Xilinx/10.1/DSP_Tools/sysgen/scripts/SgNgcVerilog.pm line 62

--------------------------------------------------------------------------------

Any comments ?

Article: 130686
Subject: Re: ISE 10.1 - Initial experience
From: austin <austin@xilinx.com>
Date: Sun, 30 Mar 2008 09:06:49 -0700
Links: << >>  << T >>  << A >>
Antti,

You (and everyone else) will probably not believe me, but there have 
been beta testers running this for more than 6 months.

Austin

Article: 130687
Subject: Re: Synthesisable Timer in VHDL
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sun, 30 Mar 2008 16:17:47 GMT
Links: << >>  << T >>  << A >>

"move" <liubenyuan@gmail.com> wrote in message 
news:ce01257f-651a-4792-aa92-6238b902e219@d4g2000prg.googlegroups.com...
> hi all:
>
> i am currently working on a "toy" design of my first big project (in
> VHDL) on the Xilinx Spartan III starter kit. now facing a timer
> problem and i could not properlly solve it using my limited design
> experience, here is it:
>
> module A will prepare data for output (node : dout(7 downto 0)) to
> module B when it receive a READY signal from B. in order to notify B
> that the data is ready on the bus , A will ouput a signal DONE , but
> the DONE will be '1' after 30 ms A received signal READY and will just
> last 10 ms before going low. I wonder is there any standard or elegant
> way of implement the timer in VHDL?
>
> PLZ give me some hint!
> thank U all in advance ! :)

1. Create constants of type time (or pass in as generics of type time) the 
clock period of your clock and the time period for your delays.
2. Based on the value of those constants/generics compute the number of 
clocks that you would need to count (i.e. Max_count := Delay_Time / 
Clock_Period)
3. Declare an integer signal in the range from 0 to Max_Count -1
4. Create the code for a counter that counts from 0 to Max_Count - 1.  When 
you get up to Max_Count - 1 your requested time interval has occurred so do 
whatever it is you want to do at that time.

Kevin Jennings 



Article: 130688
Subject: Re: ISE 10.1 - Initial experience
From: Antti <Antti.Lukats@googlemail.com>
Date: Sun, 30 Mar 2008 09:23:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 30 Mrz., 18:06, austin <aus...@xilinx.com> wrote:
> Antti,
>
> You (and everyone else) will probably not believe me, but there have
> been beta testers running this for more than 6 months.
>
> Austin

Austin,

sure I belive you! but they are not doing their job! How hard is that
to understand?

If every new major release causes instant frustration and/or has TTFFF
(time to first fatal failure) less than 30 minutes, then your beta-
testers have continously failed todo their job. I cant see it any
other way.

Antti



Antti

Article: 130689
Subject: Re: Configuring a Spartan 3A1800 ExtremeDSP from Spartan3 cable?
From: Paul Boven <p.boven@xs4all.nl>
Date: Sun, 30 Mar 2008 18:44:32 +0200
Links: << >>  << T >>  << A >>
Hi emeb, everyone,

emeb wrote:
> On Mar 20, 7:25 am, Paul Boven <boven@jive.nl> wrote:

>> Just ordered a Spartan 3A ExtremeDSP Starter Kit. It comes without a
>> programming cable, but I figured I could re-use the cable from my trusty
>> Digilent parallel cable from the Spartan-3 kit. The pinout is certainly
>> the same (6 pins single header). But I've just noticed that the Digilent
>> documentation states there is 2.8V on the connector while the new
>> Spartan-3A DSP board provides 2.5V. Will this work?

> The Digilent USB<->JTAG cable I bought a few weeks back operates from
> 1.8V - 5.5V. Which cable do you have?

The 'old' Digilent parallel cable says '2.8V to 5V' on the heat shrink 
tube over the connector: This was the one that came with my Spartan-3 
kit. Fortunately, it appears to work well with the 2.5V for the 
Spartan-3A DSP 1800A kit as well. The newer Digilent parallel cables are 
actually specified to work from 1.8V and upwards ('JTAG3 cable'). I've 
decided to stay away from USB cables for the time being, don't need even 
more hassles trying to make all this work under Ubuntu ;-)

Regards, Paul Boven.


Article: 130690
Subject: Re: async clk input, clock glitches
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sun, 30 Mar 2008 17:19:34 GMT
Links: << >>  << T >>  << A >>

"Antti" <Antti.Lukats@googlemail.com> wrote in message 
news:0139131e-741b-438b-bfb4-580a19213014@e39g2000hsf.googlegroups.com...
On 29 Mrz., 20:27, "KJ" <kkjenni...@sbcglobal.net> wrote:

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

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.

>
> most of the FPGA logic can/should be clocked with this strobe,

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.

> and i see little reasons to move all that logic into 50mhz clock domain

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.

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

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.

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

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 



Article: 130691
Subject: Re: ISE 10.1 - Initial experience
From: Alain <no_spa2005@yahoo.fr>
Date: Sun, 30 Mar 2008 10:41:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all,

Here are my first impressions :

First, I will not repeat "what's news" but I've seen some real
improvements, mainly concerning GUI (like report, for cross probing to
HDL editor with warnings, very useful; and so on...). Concerning P&R
result, at first I was quite frustrated : many timing constraints not
passed successful in 10.1 and in 9.2 every was ok. In fact 10.1
analyze more constraints (in my design, constraints between clocks,
that was in fact not relevant). After adding some "TIG" everything was
ok.
At present, I'm just worry about LUT and FF increase after map : More
Lut and FF (??? I've to investigate...) but more LUT used as Shift
registers and less slices occupied.
Concerning EDK10.1, I would be interested to know your thoughts about
the improvements or problems ...

Cheers !

Alain.



Article: 130692
Subject: Re: async clk input, clock glitches
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sun, 30 Mar 2008 19:02:06 GMT
Links: << >>  << T >>  << A >>

"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 



Article: 130693
Subject: Re: async clk input, clock glitches
From: Antti <Antti.Lukats@googlemail.com>
Date: Sun, 30 Mar 2008 12:03:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
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




Article: 130694
Subject: Re: async clk input, clock glitches
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sun, 30 Mar 2008 19:08:00 GMT
Links: << >>  << T >>  << A >>

"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 



Article: 130695
Subject: Re: async clk input, clock glitches
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sun, 30 Mar 2008 19:26:24 GMT
Links: << >>  << T >>  << A >>

"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 



Article: 130696
Subject: Re: async clk input, clock glitches
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Mon, 31 Mar 2008 07:42:45 +1200
Links: << >>  << T >>  << A >>
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


Article: 130697
Subject: Re: async clk input, clock glitches
From: Antti <Antti.Lukats@googlemail.com>
Date: Sun, 30 Mar 2008 12:59:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
> 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


Article: 130698
Subject: Re: async clk input, clock glitches
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sun, 30 Mar 2008 20:26:17 GMT
Links: << >>  << T >>  << A >>

"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 



Article: 130699
Subject: Re: async clk input, clock glitches
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sun, 30 Mar 2008 20:28:26 GMT
Links: << >>  << T >>  << A >>
In previous post...

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

KJ 





Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search