async clk input, clock glitches
Antti
FPGA has
1) 50mhz system clock from ext oscillator
2) 4Mhz clk that is async to the 50mhz
problem, the 4MHz clk input sees double clk pulse, error rate
approximate 1 to 10.000.000
unfortunatly the 4mhz clock needs to be used inside without phase
delay, so oversampling and filtering with 50mhz is not an option,
unless using very clever no delay glitch surpression filter
external small R/C circuit on 5mhz doesnt change the error rate much,
ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to
give better results as using the 4mhz clock directly
any ideas how to really clean the 4mhz clock?
or any thumb guess what is the likeliness to see double clk edges when
sampling 4mhz with async 50mhz?
could the "error rate" of such sampling be that 1:10M what I am
seeing?
I assume the 4 mhz clock is rather good, it coming from an ASIC and
has total wire lenght from asic to FPGA maybe 20 mm (but over PCB edge
connector). I did kinda think its hard to belive that the clock edge
is so slow or noisy that 50mhz sampling could ever see double/wrong
edges but guess i am wrong
it doesnt seem to be cross talk either, as there arent much IOs
toggling at all
hm it looks like in rare cases the error is also one clock pulse
missing!
:) any good suggestions are welcome, how to troubleshoot the issue
unfortunatly the FPGA is actel so can use any on-chip logic analyzer
core, and the chip is rather full also, some internal signal could be
routed out to external logic analyzer though if badly needed, but so
far i am trying to fix the issue by thinking, and error-retry...
Antti
Icky Thwacket
"Antti" <Antti....@googlemail.com> wrote in message
news:e6010199-ca1d-4540...@b1g2000hsg.googlegroups.com...
the voltage) then try putting the 4MHz clock into an onboard PLL configured
for zero delay and narrow bandwidth, then use the PLL output for internal
clocking. (Being a low life Altera user, don't know if this is available in
Xilinx parts)
Frank Buss
> Hi
>
> FPGA has
> 1) 50mhz system clock from ext oscillator
> 2) 4Mhz clk that is async to the 50mhz
>
> problem, the 4MHz clk input sees double clk pulse, error rate
> approximate 1 to 10.000.000
> unfortunatly the 4mhz clock needs to be used inside without phase
> delay, so oversampling and filtering with 50mhz is not an option,
> unless using very clever no delay glitch surpression filter
How much delay is allowed? I assume you have already latched the clock once
with every 50Mhz edge, to avoid meta stability problems. To avoid double
clock pulses, you could feed a shift register with this latched signal and
compare for "0111" and "1000" to detect edges more clean, maybe with an
additional holdoff after detection to avoid detecting spikes.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Brian Drummond
wrote:
>Hi
>
>FPGA has
>1) 50mhz system clock from ext oscillator
>2) 4Mhz clk that is async to the 50mhz
>
>problem, the 4MHz clk input sees double clk pulse, error rate
>approximate 1 to 10.000.000
>unfortunatly the 4mhz clock needs to be used inside without phase
>delay, so oversampling and filtering with 50mhz is not an option,
>unless using very clever no delay glitch surpression filter
however that doesn't stop you building analyzers (clocked on 50MHz) to diagnose
the problem
>external small R/C circuit on 5mhz doesnt change the error rate much,
series-term (22-50R) at source may be the best bet ... but with 20mm trace
length, that's unlikely to be the problem.
>ah currently the 4mhz is clocked 1 time with 50mhz, this seemed to
>give better results as using the 4mhz clock directly
Also establishes that some sort of resynch is acceptable.
>any ideas how to really clean the 4mhz clock?
>or any thumb guess what is the likeliness to see double clk edges when
>sampling 4mhz with async 50mhz?
Metastability : about once in recorded human history :-)
Other causes : e.g. crosstalk during the linear window : much higher.
>could the "error rate" of such sampling be that 1:10M what I am
>seeing?
>I assume the 4 mhz clock is rather good, it coming from an ASIC and
>has total wire lenght from asic to FPGA maybe 20 mm (but over PCB edge
>connector). I did kinda think its hard to belive that the clock edge
>is so slow or noisy that 50mhz sampling could ever see double/wrong
>edges but guess i am wrong
>
>it doesnt seem to be cross talk either, as there arent much IOs
>toggling at all
>
>hm it looks like in rare cases the error is also one clock pulse
>missing!
Build a trivial analyzer clocked at 50MHz.
count "high time" and "low time" in 50MHz cycles; log the max and min "high
time" counts (update the log after each rising edge); ditto low time.
Good results would be 6 cycles min, 7 cycles max (+/-1 from asynchronicity)
Classic edge bounce will show min high (or low) time of 1 cycle; glitches away
from edges (e.g. from major crosstalk) may show e.g. min high 1, min low 3
cycles. Missing pulses will show large "max" times.
etc
My guess would be min times of 1, i.e. double-clocking edges, from (small
amplitude) crosstalk which coincides with a slow 4MHz edge.
Oh . And does this occur on one board, or on several identical ones?
- Brian
Symon
> Hi
>
> FPGA has
> 1) 50mhz system clock from ext oscillator
> 2) 4Mhz clk that is async to the 50mhz
>
> problem, the 4MHz clk input sees double clk pulse, error rate
> approximate 1 to 10.000.000
> unfortunatly the 4mhz clock needs to be used inside without phase
> delay, so oversampling and filtering with 50mhz is not an option,
> unless using very clever no delay glitch surpression filter
>
I guess your problem is a slow edge rate on your 4MHz clock. Does this fix
it?
process(clk_50M)
begin
if rising_edge(clk_50M) then
four_meg_d <= four_meg_in;
four_meg_dd <= four_meg_d;
end if;
end process;
process(four_meg_in, four_meg_dd)
begin
if four_meg_in = '1' and four_meg_dd = '0' then
four_meg_out <= '1';
elsif four_meg_in = '0' and four_meg_dd = '1' then
four_meg_out <= '0';
end if;
end process;
HTH., Syms.
j...@amontec.com
I am almost sure your 4Mhz frequency is clean on your board. But
verify!
If your 4MHZ is stable then the trouble is coming inside your FPGA.
Before all, verify you are using a Global buffer for the 50Mhz.
Then you have to register all inputs with your 50MHz and to register
the 4Mhz input with 50MHz too (f4mhz_reg). Then verify after Place &
Route, your are using IOB registers (registers in the PADs)!
The use of IOB registers is very important.
When this is done and verified, return to your code and add a new Flip-
Flop (50Mhz) to the registered 4Mhz input (f4mhz_reg2), and detect the
rising edge of the 4Mhz by
f4mhz_rise_pulse <= '1' WHEN (f4mhz_reg = '1') AND (f4mhz_reg2 = '0')
ELSE '0';
Finally, all your flip-flops inside the FPGA core should use 50Mhz clk
and the f4mhz_rise_pulse as clock enable.
I am almost sure this will resolve your design issue.
This is a very common issue for all VHDL / FPGA students .
Hoping this resolve the problem. But resolving the trouble is not
enough. We have to understand what was really the trouble and what
happen when we do not synchronize all inputs in 2 clock domain ?
Let me know if you want to understand what really was the trouble.
- Laurent
http://www.amontec.com
----
Introducing new USB Instrument Platform (Hi-Speed USB2.0 + Xilinx
FPGA ) in a very small format. Small as a Amontec JTAGkey !
New fast JTAG interface is coming with!
KJ
"Antti" <Antti....@googlemail.com> wrote in message
news:e6010199-ca1d-4540...@b1g2000hsg.googlegroups.com...
>
> 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
Peter Alfke
Antti, click on
http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcell/xl34/xl34_54.pdf
which shows two different ways to avoid the effect of double-edges on
a clock.
I wrote that many years ago, and published it in Xilinx XCell magazine
#34
Peter Alfke
Antti
> "Antti" <Antti.Luk...@googlemail.com> wrote in message
Hi all and thanks for all suggestions!
some additional info
failing circuit
ASIC outpu t> 15mm trace > connector > 5mm trace > 27 ohm > 3mm trace
FPGA input >
>F-F strobed with 50mhz > global clock buffer > 2 bit counter
now, this 2 bit counter sees
* double clock from asic in about 1:10M pulses
* missing clock from asic in about 1:100m pulses
the asic clock is know to be perfect many other devices can receive it
and have 0 error rate (have not seen error ever!)
the 50mhz clock signal quality, well it doesn matter, as whatever
could be wrong, it could not explain the double and missing pulse
counts ?
using PLL on 4mhz is not an option as it is not free running clock but
byte strobe with 4mhz pulses
so what is failing is really simple circuit!
it also looks like when double pulses are seen the FPGA is not
changing any of its output so its no SSO noise
I could understand power supply noise to cause double pulses, but how
to explain the missing pulses?
I dont have scope here now, but i have tried to troubleshoot the clock
problem before and have looked the signals with scope without seeing
anything helpful to get to the problem, i will do it again if I dont
get it working this weekend
the timing analyze with actel FPGA is something so:so, I have seen a
shift register clocked at 4mhz working 100% when FPGA utilization
below 90% and failing 100% when FPGA utilization over 90%, without any
problem reported by the timing tools or post place simulation. I wasnt
belive my eyes when i did see that, but so it was. Later i found some
actel appnote about methods of dealing with such cases. I hoped that
actel tools take of such situations but they do not.
so I have little hope that some more detailed timing analyzes gives
the solution to the problem
at the moment the 4mhz strobe should have small internal delay so 2 FF
at 50mhz is already too much, so i need either deglitch with no phase
delay or then need change my other logic to tolerate the delay
I have some other options too, but all they are not so simple and easy
to implement, so I am hoping some magic hint to fix the problem :)
will try use the 4mhz directly and measure error rate, with 50mhz
running and disabled, as last resort i can use other free running
clock entering FPGA from different side and PLL, and disable the 50mhz
oscillator completly this should hopefully decrease the overall power
and crosstalk noise
Antti
Antti
>
> which shows two different ways to avoid the effect of double-edges on
> a clock.
> I wrote that many years ago, and published it in Xilinx XCell magazine
> #34
> Peter Alfke
Hi Peter,
thanks I do know those things think also but i still printed the xcell
pages out :)
now, in Xilinx FPGA I dont see the problem :)
but the final target is actel FPGA (because: cost+security+package)
and in Actel i see both double and missing clocks
so i am still puzzled, there must be something very basic bad thing
somewhere
Antti
mk
<al...@sbcglobal.net> wrote:
>Antti, click on
>
>http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcell/xl34/xl34_54.pdf
>
>which shows two different ways to avoid the effect of double-edges on
>a clock.
>I wrote that many years ago, and published it in Xilinx XCell magazine
>#34
>Peter Alfke
I think it's highly humorous for a Xilinx employee to post a link to a
university in India for a document which Xilinx has created but unable
to archive apparently.
mk
Actually the whole magazine is tucked away at a directory on Xilinx
FTP site but google doesn't seem to like FTP sites too much so a
search doesn't get you there.
KJ
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 do, there is
inherent design skew that can not be eliminated and yet can not be tolerated
either.
> the timing analyze with actel FPGA is something so:so, I have seen a
> shift register clocked at 4mhz working 100% when FPGA utilization
> below 90% and failing 100% when FPGA utilization over 90%, without any
> problem reported by the timing tools
Is there an option in the timing analysis that causes it to not analyze
clock domain transfers? I know with Altera, the default is to not analyze
paths that start in one clock domain (i.e. the 'synchronized 4 MHz' domain)
and end in another (i.e. the 50 MHz domain). When you turn that option on,
it does do the analysis. Check with the Actel stuff to see how it analyzes
(or doesn't) stuff in between two domains.
> or post place simulation.
In my experience, post route simulation generally does not catch any timing
problems....it just takes a long time to do and really doesn't catch hardly
anything.
> I wasnt
> belive my eyes when i did see that, but so it was. Later i found some
> actel appnote about methods of dealing with such cases. I hoped that
> actel tools take of such situations but they do not.
>
Not sure what you're referring to here.
> so I have little hope that some more detailed timing analyzes gives
> the solution to the problem
>
Given that you're (likely) operating this in a non-radioactive, Earth bound
environment, the only things that will cause intermittent failures though as
I stated earlier are:
- Timing
- Signal quality
- Power
Nothing else.
Since signal quality and power don't appear to be the most likely suspects
based on what you've posted, that leaves timing as the lurking design issue
so timing analysis will find the problem.
> at the moment the 4mhz strobe should have small internal delay so 2 FF
> at 50mhz is already too much, so i need either deglitch with no phase
> delay or then need change my other logic to tolerate the delay
>
Since you're only driving a two bit counter, I'd suggest instead that you
get rid of the synchronizing flop on the 4 MHz and instead use it as the
direct input to a two or three bit shift register that is clocked by 50 MHz.
Inherently then you're building in the proper synchronization, and the
outputs of the shift register will all be in the 50 MHz clock domain, not
something that you hope to be close to it (i.e. the 'synchronized 4 MHz'
domain). Except for the very first shift reg output those other outputs can
be combined however needed to emulate whatever it is that you were really
doing with the 2 bit counter.
I'm suspecting that it shouldn't take too much effort to make the 2 bit
counter run off of the 50 MHz with a clock enable signal that is computed by
combinatorially combining the last two taps of the shift register (i.e.
Tap(2) and not(Tap(3)).
> I have some other options too, but all they are not so simple and easy
> to implement, so I am hoping some magic hint to fix the problem :)
Magic won't help ;)
> will try use the 4mhz directly and measure error rate, with 50mhz
> running and disabled, as last resort i can use other free running
> clock entering FPGA from different side and PLL, and disable the 50mhz
> oscillator completly this should hopefully decrease the overall power
> and crosstalk noise
Except that you haven't measured anything that indicates that power supply
noise or crosstalk is the issue.
Kevin Jennings
Mike Treseler
> any ideas how to really clean the 4mhz clock?
I would try soldering on one of those
little schmitt trigger packs. Sometimes
a low slew rate will clock both edges
once in a while.
-- Mike Treseler
Antti
yes schmit trigger input could be the cure..
but i still cant understand the missing clock pulses!
Antti
KJ
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. Have you taken a scope to that signal and
measured the edge rate?
Kevin Jennings
Jim Granville
> On 29 Mrz., 18:00, Peter Alfke <al...@sbcglobal.net> wrote:
>
>>On Mar 29, 2:41 am, Antti <Antti.Luk...@googlemail.com> wrote:
>>
>>
>>
>>
>>>Hi
>>
>>>FPGA has
>>>1) 50mhz system clock from ext oscillator
>>>2) 4Mhz clk that is async to the 50mhz
>>
>>>problem, the 4MHz clk input sees double clk pulse, error rate
>>>approximate 1 to 10.000.000
> Hi Peter,
>
> thanks I do know those things think also but i still printed the xcell
> pages out :)
> now, in Xilinx FPGA I dont see the problem :)
> but the final target is actel FPGA (because: cost+security+package)
> and in Actel i see both double and missing clocks
>
> so i am still puzzled, there must be something very basic bad thing
> somewhere
Hi Antti,
If you have a clean design using Xilinx, and the EXACT SAME (?)
design fails in Actel, then that does seem to exclude the ASIC.
Does Actel have pin Hysteresis ?
Can you move the 4MHz pin about on the device, and check the
failure stats ?.
Try a tiny-logic schmitt right at the Actel device ?
And also try a Tiny-Logic D-FF as an external syncroniser.
Can you simplify the Actel logic to the very lowest to verify clock
integrity
(even some test code that is a FreqDetector, looks for 2MHz or 8MHz
timeframes, and sticky latches (or counts) - should be only a few FFs,
then try this with/without the rest of ther chip alive.
The only time I've seen double clocking, is on slowish edges,
on pins without Hysteresis.
(oh, and when I've gone looking for it, with test waveforms :)
Cables are NOT nice, as they have significant series inductance.
Floating pins have done strange things too, as I suspect the
buffer stages go into transistion oscillation, at very high
frequencies, and the internal ground inductance is simply too high
at those frequencies and things get 'quite confused'
-jg
Jim Granville
> 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
10M is at 4MHz rate so every 2.5s, and 25 secs ?
Can you clarify the double-clocking ?
Do you mean one 4Mhz Edge, causes two INCs, 20ns apart ?
(rather than the expected INC @ 250nS +/- 20ns ) ?
What if you set up two of these one on each 4MHz edge ?
- are the error stats the same on rising/falling ?
-jg
Jim Granville
> the timing analyze with actel FPGA is something so:so, I have seen a
> shift register clocked at 4mhz working 100% when FPGA utilization
> below 90% and failing 100% when FPGA utilization over 90%, without any
> problem reported by the timing tools or post place simulation. I wasnt
> belive my eyes when i did see that, but so it was. Later i found some
> actel appnote about methods of dealing with such cases. I hoped that
> actel tools take of such situations but they do not.
That may not be a 'tools' problem at all, but could be a real hardware
issue. It is unlikely their test coverage is that great in
such 'corner cases' - most vendors expect you to go to a larger device
when you hit 90% ! :)
As more and more of the device is active, the ground noise and
crosstalk has to get steadily worse - what external loads is the device
driving, and what package ?.
I get the impression this was part of the driving force behind the
flip-chip-bga and all-die-bondpads
-jg
Peter Alfke
> On Sat, 29 Mar 2008 10:00:50 -0700 (PDT), Peter Alfke
>
> <al...@sbcglobal.net> wrote:
> >Antti, click on
>
>
> >which shows two different ways to avoid the effect of double-edges on
> >a clock.
> >I wrote that many years ago, and published it in Xilinx XCell magazine
> >#34
> >Peter Alfke
>
> I think it's highly humorous for a Xilinx employee to post a link to a
> university in India for a document which Xilinx has created but unable
> to archive apparently.
Not so strange when the Xilinx employee (and incidentally also the
author of the article) is at home and in a hurry, and just googles for
the first hit.
Who cares about geography in the age of the internet...
Peter Alfke
Jim Granville
> "Antti" <Antti....@googlemail.com> wrote in message
> news:860e9a98-ef7c-4228...@i7g2000prf.googlegroups.com...
>
>>On 29 Mrz., 20:34, Mike Treseler <mike_trese...@comcast.net> wrote:
>>
>>>Antti wrote:
>>>
>>>>any ideas how to really clean the 4mhz clock?
>>>
>>>I would try soldering on one of those
>>>little schmitt trigger packs. Sometimes
>>>a low slew rate will clock both edges
>>>once in a while.
>>>
>>> -- Mike Treseler
>>
>>yes schmit trigger input could be the cure..
>>but i still cant understand the missing clock pulses!
Wait until you have it proven-fixed, before making
guesses :)
>>
>>Antti
>
>
> 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.)
-jg
Antti
>
> 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
Antti
>
> Erfahren Sie mehr »
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
>=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
Antti
Icky Thwacket
Hi Kevin,
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.
Antti
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
Icky Thwacket
>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.
Falk Brunner
[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
Antti
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
Antti
> >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.
KJ
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
Jim Granville
<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
KJ
"Jim Granville" <no....@designtools.maps.co.nz> wrote in message
news:47ef...@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
Antti
wrote:
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
KJ
> 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
KJ
>
> 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
Antti
> 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
KJ
>> Post-place sims do not catch timing errors, they do not catch
>> metastability
>> problems. Generally they just take a long time to run.
>>
>> > my failure rate change may also be just different fitter run
>> > differences. I have no almost all working, that is no double or
>> > missing strobes, and the 50mhz domain part also working ok
>>
>> Congrats....now try the freeze spray and the hot air gun to make sure
>> that
>> you're not sensitive to temperature
>>
>> KJ
>
> Kevin
>
> in actel FPGA following is possible:
>
> design including "one sincle clock 4mhz clocking a 32 bit wide shift
> register" all signals are perfect as signal quality
>
> now while this ALWAYS works when the rest of the FPGA is empy, it may
> also ALWAYS fail, if the rest of the FPGA is full (if the clock uses
> local routing).
>
> now if the routing delay and internal skew in FPGA cause place-and-
> route result that NEVER works, see actel appnote, then this delay
> SHOULD be known for the FPGA tools,
And 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
KJ
- Fast model (i.e. 'fast' part, prop delays at their fastst)
KJ
j...@amontec.com
Schmit trigger will not help you.
Please try to register all inputs, verify the FFs are in the IOB pads,
and your troubles will go.
It is very easy to understand the missing clock pulses: your 4mhz
signal used as strobe controls many FFs in your design. But actually,
you do not control the timing propagation of the combinatorial logic
from the pad to these FFs.
When a rising of 50mhz is very close to the rising_edge 4mhz, some FFs
see the 4Mhz signal as a 0 logic level and some others see the 4 Mhz
signal as a 1 logic level... and YOU LOSE SOME EDGE ON SOME FFs
Very common error !
Laurent
www.amontec.com
Antti
Larry, there error happened when 1 single FF was clocked with 50mhz
and having 4mhz pulses in D.
the output from this FF did miss one COMPLETE pulse (one rising edge)
in about 1 per 100M pulses counted.
that can only happen if the pulse was not latched proper level for
many clocks of 50mhz, something i can really not understand.
well all those errors have disappeared happily, without schmit trigger
or any other magic
Antti
Jim Granville
>
> 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.
These days, very large reliance is placed on the models, these
post-place-sims are still SIMULATIONS, and they rely on the
numbers the vendor gives for their models.
Those numbers often come from relatively simple bench tests, and
are not derived from 'aggressive corner killer' designs.
Sometimes it is a good idea to go looking for problems -
we have provided (or helped provide) test cases to a few
large US coporations, and I am bemused by their lack of what
I would call 'test coverage'.
>
> 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
Can you lock the Test portion, so you know that does NOT change.
You will of course get more jitter on the 4MHz clock chain,
with more of the device 'otherwise active', and that may be enough to
trigger these aperture effects.
The models SHOULD safely margin all cases, and it sounds like they may
be close, but not close enough ;)
How easy is it to edit the models in the Actel devices ?
What margin does it 'think' it has now ?
-jg
Jim Granville
> "Jim Granville" <no....@designtools.maps.co.nz> wrote in message
> news:47ee...@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.
Yes, but it does more as well. The output of a schmitt now references
against the local ground, and so you have increased the tolerance of
inter-system ground bounce.
> 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.
Of course, but we work in the real world and if (eg) the design
has to work across multiple PCBs, then the 'proper grounding'
may not be on the table.
Differential signaling is great, but you may be forced to deploy to
a i2c or SPI interface standard - or just be told that many wires
are too expensive!,
Schmitts also allow designers to deploy EMC measures, often late
in the design flow.
Pin Configurable schmitts are common in CPLDs, and I know one vendor
who put them there, because we provided examples of when/how they
were needed in real world applications.
-jg
KJ
Just what was the change anyway? Getting rid of using the strobe to clock
things or something else?
KJ
Antti
> "Antti" <Antti.Luk...@googlemail.com> wrote in message
well as soon as the strobe is passing one FF clocked at 50mhz
there was measurable error rate for both extra and missing strobes.
thats basically it. I had some of the design tested on Xilinx and bad-
proto
where I had to filter the signals, so at design change i removed some
filters
and in the strobe left 1 FF what looked like good solution until i did
start
to measure the actual error rate..
Antti
Nial Stewart
getting on.
Can you post an update and describe what the problem turned out
to be?
Nial.
Peter Alfke
Let me make a categorical statement:
When a high-frequency clocks a flip-flop that has a significantly
lower frequency on its D input (which is what Antti descibes) then
there is NO POSSIBILITY for the flip-flop Q output to have FEWER
transitions than its D input. But there can be additional transitions
on Q due to slow data transitions, noise, and even the rare
metastability. But NEVER a missing transition on Q.
Peter Alfke
Antti
hi Peter,
you know was almost to ask this in private (to save embarrassement)
from what I understand I also did think that the Q can not have
missing (less) transactions.
thats why my results did wonder me so much:
1:10M double (extra transition)
1:100M missing transition
now the signal and PCB are know be ok, and without the FF in the
strobe line there are no error as long as i have tested >6hours, not
single error.
the input signal is actually very good one, so I would bet even the
1:10M extra transitions is too much (well here I dont know for sure if
there is any rule of thumb to calculate this ration)
eh, I wisch I could have choose Xilinx FPGA this project, as the first
Xilinx based prototype worked without any issues ever seen. But
unfortunatly the target device is Actel, where the fabric is very
different, and device is way too small also :(
ok, the rd_wr_strobe errors I got fully rid off, but my full design
still has errors, which also may be related so some strobe/clocking
the first "glitch" strobe was one of 2 async interfaces, there other
being slave SPI in FPGA, where external MCU is SPI master at about 4
mhz spi clock.
the second interface reads 8 bytes, and writes 3 bytes
while all the reads are always good, in the data path external SPI
into FPGA seem again be random errors, with rather high rate, but the
logic is only 2 shift registers
one shifting in SPI data, and the other being initialized from the spi
shift register.
no on this path, seems also be some violation.. so i am still
debugging my design :(
this secondary SPI is where i did see the shift register to fail (when
it uses local routing), but now it is forced global clock, and besides
that shift register there is only one load to another register that
may be failing.
working step by step closer to the place where the last error could
be. eh without onchip logic analyzer it not so fun, and adding it is
out of the question, only if route out and use some xilinx board to
desirialize trace data
Antti
Nial I was about to answer you too, but I wasnt online
KJ
While while you said is true, Antti and you (I think) are both
assuming that there was a missing transition on the output of the flop
that Antti put on the input strobe. While that would produce the
symptoms that he saw, it is not possible as you've noted.
Keep in mind that Antti never actually measured a missing strobe, he
never even measured a skip or hiccup on the two bit counter that the
strobe was clocking. What he did measure were other downstream
symptoms that could be explained by a missing strobe...or by a two bit
counter that counted 4 times instead of 1...or by one that counted
incorrectly in some other fashion due to failing timing.
The symptoms that he did report could be explained by failing timing
(it's not clear that timing analysis on both fast and slow sides or
cross clock domain analysis was performed even when I specifically
asked that). Another issue is that the flop output has potential for
metastability which then creates possibilities for creating additional
clocks inside the device which might be violating timing as well or
simply clocking the two bit counter more times that expected to give
the system level appearance of a 'missing' strobe.
Getting rid of the flop on the strobe input pin thereby allowing the
input pin to basically be used to clock whatever it is that needs
clocking with that signal, seems to have gotten Antti's design over
the hump. Take your choice, I'll lean towards the explainable
hypothesis rather than the unexplainable one at any time.
Kevin Jennings
Antti
Hi Kevin,
yes i only monitored a table lookup addressed by the 2 bit counter.
correct the "missing" could have been extra 3 clocks, but well
I measured in chunks of 12 strobes, and withing those 3 strobes
either was 1 extra
or 1 missing, this could have been 3 extra also
but a case 2 exra was never seen
so I assumed the possibility that
1 extra clocks comes 1:10M
2 extra clocks NEVER
3 extra clocks 1:100M
while missing clock could have basically been 3 clocks, well it looked
very inlikely that withing 12 clocks only either 1 or 3 extra clocks
happen, also i think the error ratio of 3 vs 1 extra should have been
greater.
whatever speculations all, as the test was not done clean enough..
Antti
Antti
Quote from Actel website: "In March 2008, it was discovered that a
potential advanced optimization could cause a logic gating of a global
signal. This optimization is part of a set of other routing
optimizations that could be invoked if a user sets the Routing High
Effort Mode in the Advanced Option of the Layout."
This is fixed in Libero 8.3 released march 31 2008
I use the exact target device and setting as described at actel
website, so I assume at least some of the mess i have had may as well
be caused by this global signal gating in high effort mode.
Folks, dont think I am not trying hard enough, I am, but the tools
sometimes choke as well. The code that I currently have, and that is
randomly failing, whatever constraints, in any normal FPGA fabric with
no tool injected mess, it SHOULD WORK, but it isnt.
Of course, the tools should be the last thing to blaim on, but
sometimes they are the root of evil
I try the 8.3 tools and hope it is fixing the issues i have
Antti
Jon Elson
Antti wrote:
> failing circuit
>
> ASIC outpu t> 15mm trace > connector > 5mm trace > 27 ohm > 3mm trace
> FPGA input >
>
>>F-F strobed with 50mhz > global clock buffer > 2 bit counter
>
>
> now, this 2 bit counter sees
> * double clock from asic in about 1:10M pulses
> * missing clock from asic in about 1:100m pulses
>
> the asic clock is know to be perfect many other devices can receive it
> and have 0 error rate (have not seen error ever!)
> the 50mhz clock signal quality, well it doesn matter, as whatever
> could be wrong, it could not explain the double and missing pulse
> counts ?
>
> using PLL on 4mhz is not an option as it is not free running clock but
> byte strobe with 4mhz pulses
OK, how long does the data stay available after the strobe? If greater
than 20 ns,
you can register the 4 MHz clock and then clock the data bits by
enabling the register. If the data has to be clocked from the 4 MHz,
then you can use the 4 MHz as a clock to the register, and set a bit,
too. That bit tells another register to copy the data from the register
that is clocked by the 4 MHz clock. So, you crossing the clock boundary
at the already latched parallel data, not the clock itself. You can put
whatever filtering is needed in to qualify the 4 MHz clock edges, if
needed, like reject any clock edge within 40 ns of one that you accepted.
Jon
Jon Elson
Antti wrote:
> 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
>
Ugh! Analog FPGAs! Something I don't want to hear about!!!! You may
want to look at these clocks (both of them) with a fast analog scope or
a really good digital one. Even if the 4 MHz clock is extremely clean
with great rise/fall times, if the 50 MHz is noisy or has slow edges,
you'd hardly know the difference. What I'm trying to say is jitter or
double clocking of the 50 MHz clock could foul up the relationship
between it and the 4 MHz, although I guess it would have to be truly
horrible to do that, and the symptoms would undoubtedly show up
somewhere else, too. Is the 50 MHz processed by PLLs? Noisy power
could affect the locking of the PLL. Good luck, but I doubt you are
going to really nail this without serious scope probing.
Jon
Peter Alfke
Well, if you worry about double-clocking, there are simple bad-aid
fixes that let you live with the double edges: click on
http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcel...
which shows two different ways to avoid the effect of double-edges on
a clock.
I wrote that long ago, and published it in Xilinx XCell magazine #34
Peter Alfke (repeat of my posting of several days ago)
Peter Alfke
> On Apr 2, 3:57 pm, Jon Elson <el...@wustl.edu> wrote:
>
>
>
> > Antti wrote:
> > > 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
>
> > Ugh! Analog FPGAs! Something I don't want to hear about!!!! You may
> > want to look at these clocks (both of them) with a fast analog scope or
> > a really good digital one. Even if the 4 MHz clock is extremely clean
> > with great rise/fall times, if the 50 MHz is noisy or has slow edges,
> > you'd hardly know the difference. What I'm trying to say is jitter or
> > double clocking of the 50 MHz clock could foul up the relationship
> > between it and the 4 MHz, although I guess it would have to be truly
> > horrible to do that, and the symptoms would undoubtedly show up
> > somewhere else, too. Is the 50 MHz processed by PLLs? Noisy power
> > could affect the locking of the PLL. Good luck, but I doubt you are
> > going to really nail this without serious scope probing.
>
> > Jon
>
> Well, if you worry about double-clocking, there are simple bad-aid
> which shows two different ways to avoid the effect of double-edges on
> a clock.
> I wrote that long ago, and published it in Xilinx XCell magazine #34
> Peter Alfke (repeat of my posting of several days ago)
sloppy typing: I meant "band-aid fixes", since some purists insist
that it is bad practice to live with such a problem. But I prefer a
band-aid to the alternative of spreading blood all over the place or
even bleeding to death.
Peter
Torsten Landschoff
On 3 Apr., 01:49, Peter Alfke <pe...@xilinx.com> wrote:
> Well, if you worry about double-clocking, there are simple bad-aid
> fixes that let you live with the double edges: click onhttp://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcel...
> which shows two different ways to avoid the effect of double-edges on
> a clock.
> I wrote that long ago, and published it in Xilinx XCell magazine #34
I was curious about that article. I don't currently have any related
problem but learning these tricks might help me down the road.
Unfortunately the link you posted is dead. I tried to dig it up from
the xcell archives on xilinx.com, but the last issue available is #48.
It would be nice to have the older issues available as well,
especially for newcomers who can still learn some basic/historical
stuff from that.
Do you know another archive?
Greetings, Torsten
Nial Stewart
> problem but learning these tricks might help me down the road.
>
> Unfortunately the link you posted is dead. I tried to dig it up from
> the xcell archives on xilinx.com, but the last issue available is #48.
> It would be nice to have the older issues available as well,
> especially for newcomers who can still learn some basic/historical
> stuff from that.
Here's the full link Peter posted a couple of days ago...
http://www.nalanda.nitc.ac.in/industry/appnotes/xilinx/documents/xcell/xl34/xl34_54.pdf
Nial
Symon
Muzaffer Kal
For an official source of older XCell magazines go here:
ftp://ftp.xilinx.com/pub/documentation/xcell/00_index.htm
the specific issue is here:
ftp://ftp.xilinx.com/pub/documentation/xcell/xcell34.pdf
with the article starting on page 54.
Antti
updating to 8.3 did not fix the problems, but I am getting closer
status:
in desing exist async strobes A1, A2 (A1 byte rd/wr strobe, A2 spi
slave from ext mcu)
loadable LFSR in A1 domain
2:1 MUX for the selecting the load value
1 input of mux = const, loaded at powerup
2 input of mux connected to 24 bit shift register in A2 domain
LFSR is loaded with constant at powerup, and loaded
with current value in spi shift register ONCE, after
that load the load enable signal is FULLY DISABLED
now, the actual loads to the LFSR work 100%
but when the there is data shifted in into the spi shift
register connected to the input mux of the LFSR load input
then some sequences of data make the LFSR content corrupt
these sequences are REPEATABLE, that is not random!
for different FPGA implementiation runs the sequences are
different, but still for given PCB/FPGA bitstream they are
constant. That is the LFSR gets corrupted at certaing
values being visible on the load input via mux
I already have forced the LFSR enable and mux select
to global clocks
of course the SPI clock and LFSR clocks are global
clocks as well
Antti
Brian Drummond
wrote:
>On 2 Apr., 18:22, Antti <Antti.Luk...@googlemail.com> wrote:
>> On 1 Apr., 14:31, "Nial Stewart"
>>
>> <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
>> > I've read all the posts here but have lost track of how you're
>> > getting on.
>>
>> > Can you post an update and describe what the problem turned out
>> > to be?
>>
>> > Nial.
>>
>> Quote from Actel website: "In March 2008, it was discovered that a
>> potential advanced optimization could cause a logic gating of a global
>> signal.
>> This is fixed in Libero 8.3 released march 31 2008
>updating to 8.3 did not fix the problems, but I am getting closer
>status:
>in desing exist async strobes A1, A2 (A1 byte rd/wr strobe, A2 spi
>slave from ext mcu)
>
>loadable LFSR in A1 domain
>2:1 MUX for the selecting the load value
>1 input of mux = const, loaded at powerup
>2 input of mux connected to 24 bit shift register in A2 domain
>
>LFSR is loaded with constant at powerup, and loaded
>with current value in spi shift register ONCE, after
>that load the load enable signal is FULLY DISABLED
>but when the there is data shifted in into the spi shift
>register connected to the input mux of the LFSR load input
>then some sequences of data make the LFSR content corrupt
>
>these sequences are REPEATABLE, that is not random!
As I understand it, the SPI register and the LFSR register are on different
clock domains; with purely combinational logic (the mux, and the Load Enable)
between them.
In Xilinx, as I understand it, if a 4-Lut transitions between one
Load_Enable=FALSE state, and another Load_Enable=FALSE state, it is guaranteed
not to glitch via a Load_Enable=True state.
I don't know Actel at all - is the same guarantee true there?
If not, I believe you need an intermediate register (just a simple pipeline
register) clocked in the LFSR clock domain, to hold a copy of the SPI shift
register. (This copy is subject to metastability, but with a tiny window of
opportunity). Whereas now, you are exposed to the possibility of glitches
derived from the SPI clock, and latched on the LFSR clock.
> That is the LFSR gets corrupted at certaing
>values being visible on the load input via mux
... or certain TRANSITIONS being visible on the load input?
IF the mux and the load enable logic are rolled into the same combinational
cloud, AND 0->0 via glitch 1 is possible, then you are exposed to invalid values
during a settling time window after the ... wrong clock.
>I already have forced the LFSR enable and mux select
>to global clocks
I'm not sure that helps (it may reduce errors by an order of magnitude or more,
but it leaves you open to the possibility above)
>of course the SPI clock and LFSR clocks are global
>clocks as well
... good...
just a guess but on the information given, it looks plausible to me.
- Brian
Antti
> On Fri, 4 Apr 2008 23:56:37 -0700 (PDT), Antti <Antti.Luk...@googlemail.com>
Hi Brian,
the story goes even more fascinating (or frustrating)...
first about Actel - their Logic Cell is NOT LUT based, so the
LUT input transition glitches can not happen (no LUT!) but
actel cell has NO DEDICATED flip-flop, and flip flops are
configured out of logic, and have severe restrictions on
configuration and routing, FF with enable and clear are
made out 2 cells if CLR signal is not driven by global clock
sometimes 4 cells are used to make 1 single flip flop.
the use of global clocks in actel, sometimes its not
"order of magnitude" difference but simple OK vs FAIL 100% issue
case: 64 bit shift register (no enable just shift), clocked with CLEAN
clock at 4mhz
work 100% when FPGA is almost empty (no matter what signal drivers
shift reg clock)
fails 100% when FPGA is >90% and shift clock is ruouted with local
connects
PROVEN. this is also explanaibale, and actel has special appnote for
this (clock skew handling)
==
now to my clocking issue
after taking a break I tried to eliminate things from the problem, so
I stopped shifting data
into the SPI shift register. this however made no difference, and when
i looked again
it was also explanaible as my test counter value was decoded in
external AR MCU
but the bytes holding the counter value did never get back into the
FPGA!
so to summarize again:
1) ARM9 SW has counter, that is used to generate 8 byte encrypted
token
2) those 8 bytes are going into FPGA over A1 parallel interface they
are written into dual port BRAM
3) those 8 bytes are read by AVR over SPI interface
4) AVR decodes those bytes, it also decodes the counter from step 1,
NO ERROR ever here
5) AVR writes 3 bytes to FPGA SPI shift register
6) AVR strobes to load LFSR, and set one time flag that prevents
further LFSR loads
7) ARM9 sends packets in loop (encrypted counter)
now, the counter value NEVER exist inside FPGA
the data passed via FPGA is not decoded there
the data passed via FPGA is not used by the logic responsible for the
load/enable of the LFSR
still at some certain counter value, the LFSR does get corrupted!!
those values are repeatable, they are not random, that is each time
the ARM9 counter is
restarted then at exactly same counter values the LFSR is corrupted.
those values are however different for different PCB+bitstream
combinations
8) AVR puts FPGA into main mode
9) ARM9 sends any packets any number of hours LFSR corruption no
longer happens! no single errror seen
errors happen at [7] at const numbers of counter
error NEVER happen at [9] while streaming random data for hours..
so there is no different transitions on the load input of the LFSR at
all, still there is repeatable dependancy
on the data stream that only passes through FPGA
eeee... [8] what happens there?
well after main mode the AVR no longer collects data from FPGA and no
longer decrypts it.
but that should no have any influence as the decrypt result wasnt
passing into the FPGA anyway.
there is one more difference,
after [8] the LFSR is enabled for 8 clocks lonfer for each packet from
A1 interface
but the LFSR enable/load signals do not share any logic with any of
the data lines !!
Ok, when found out that the counter data is not passing into the load
input at all, i did take a walk
and coffee break, and did write a list of options that can be tested,
list with 6 items, so will work
them out one by one
my bet is that I need add delay on the LFSR enable signal, there is no
explanation why it should
be used as it is already a FF in the same clock domain as the LFSR
clock, but all other items
on my list of possible problems are even less likely (or harder to
test)
Antti
Antti
status: ALL ISSUES SOLVED
I wonder how many guesses what the problem really was? :)
I check one item from my list, what made no difference.
luckuly i did not continue with my lists, as the real problem was not
there anyway.
sure, pure human error, there WAS dependancy on the data being pushed
into FPGA
there should not have been but it was, because some signal had wrong
name.
the same design error was already in intitial xilinx prototype a year
ago but
was never seen as it only happened 1:256 at startup
while converting to Actel, i first reduced decode from 8 to 4 bits
getting 1:16 errors
and later to 3 bit getting 1:8 errors
when I made my test with counter and got errors at some counter value,
i did
not print out the data bytes (8 byte encrypted) as I assumed them to
be random
but if i would have printed them out anyway, i would have seen at that
any time
when error happend 3 bits from 8 byte had constant value.
that 3 bit value caused the LFSR enable to be of wrong duration.
but, fixing it wasnt still so easy. After seeing the problem i fixed
the it.
then did make BIT file, and 2 different PCB boards did not work at
all :(
!?
after that I managed to get the micro-SD card with the test program
corrupted
so badly that if insert that SD into card reader on Vista then Vista
explorer HANGS
(need power off !!) on XP it just cant access the card.
ok, I get another sd card, put the test program onto it,
and I see again the same errors ??
after really really fixing the VHDL
I did rerun synplify and designer many times, to be sure
they really generate new bit file, still the same error was there!
guessed already?
sure the Actel Flashprogramming tool had remembered wrong location for
the bit file, so I used the wrong one.
when the fixed bit file really got into the FPGA, then it worked as it
was supposed
Antti
hope the thread wasnt so entirely boring :)
Brian Drummond
wrote:
>On 5 Apr., 19:37, Antti <Antti.Luk...@googlemail.com> wrote:
>> On 5 Apr., 14:41, Brian Drummond <brian_drumm...@btconnect.com> wrote:
>> Hi Brian,
>>
>> the story goes even more fascinating (or frustrating)...
>
>status: ALL ISSUES SOLVED
>
>I wonder how many guesses what the problem really was? :)
>sure, pure human error, there WAS dependancy on the data being pushed
>into FPGA
>there should not have been but it was, because some signal had wrong
>name.
So we were all looking in the wrong place...
it happens!
>Antti
>hope the thread wasnt so entirely boring :)
Not at all ... Glad you got it sorted.
- Brian