async clk input, clock glitches

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.

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

KJ wrote:

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

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

"Antti" <Antti.Lukats@googlemail.com> wrote in message 
news:ff1c62b5-f856-4740-9c12-5e303525500b@s13g2000prd.googlegroups.com...
> On 30 Mrz., 22:42, j...@amontec.com wrote:
>> On Mar 29, 9:59 pm, Antti <Antti.Luk...@googlemail.com> wrote:

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

Just what was the change anyway?  Getting rid of using the strobe to clock 
things or something else?

KJ 

On 30 Mrz., 23:34, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Antti" <Antti.Luk...@googlemail.com> wrote in message
>
> news:ff1c62b5-f856-4740-9c12-5e303525500b@s13g2000prd.googlegroups.com...
>
> > On 30 Mrz., 22:42, j...@amontec.com wrote:
> >> On Mar 29, 9:59 pm, Antti <Antti.Luk...@googlemail.com> wrote:
> > 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
>
> Just what was the change anyway?  Getting rid of using the strobe to clock
> things or something else?
>
> KJ

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

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. 

On Apr 1, 5:31=A0am, "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.

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

On 1 Apr., 18:52, Peter Alfke <pe...@xilinx.com> wrote:
> On Apr 1, 5:31 am, "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.
>
> 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

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

On Apr 1, 12:52=A0pm, Peter Alfke <pe...@xilinx.com> wrote:
> On Apr 1, 5:31=A0am, "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.
>
> 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
Peter,

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

On 1 Apr., 20:28, KJ <kkjenni...@sbcglobal.net> wrote:
> On Apr 1, 12:52 pm, Peter Alfke <pe...@xilinx.com> wrote:
>
> > On Apr 1, 5:31 am, "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.
>
> > 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
>
> Peter,
>
> 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

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

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