async clk input, clock glitches

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

:)

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

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

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.

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

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

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

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

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

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

ay

Well, if you worry about double-clocking, there are simple bad-aid fixes that let you live with the double edges: click on

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)

may

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

on

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

Here's the full link Peter posted a couple of days ago...

Nial

archive.org

on

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.

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

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.

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

... good...

just a guess but on the information given, it looks plausible to me.

- Brian