fifo or sdram bug?

Am Donnerstag, 13. August 2015 21:00:07 UTC+2 schrieb kaz:

I have seen random/strange issues with Altera FIFOs in the past more than o nce (but still seldom). In that cases I replaced the FIFOs with "home grown " ones and the problems were solved. I never tracked that down in detail (m aybe it was related to the clear signal in some way...) and I also cannot r emember details (one or two clocks, same or different width in/out), I have used so many FIFOs (mostly successfully) over the years...

I would suggest to look at all inputs and outputs of the FIFO with SignalTa p and see if it behaves correctly.

P.S.: Oh, I just read your initial post that you cannot reproduce it in the lab...

P.P.S.: I have googled around to find an old post of me regarding this. I f ailed. But I found this:

formatting link
d11182011_10.html and this:
formatting link
d02232015_507.html (Maybe there are more...)

So I would suggest to replace the FIFOs with a home grown approach and look if this solves the issues in field...

Regards,

Thomas

formatting link
- Home of EEBlaster

Reply to
thomas.entner99
Loading thread data ...

Thanks Thomas. These two links could explain it well though my quartus is older version but I assume Altera have bug in reporting their bug as well. The link says the possibility of failure increases with speed and logic size. Our speed of 368.64/245.76MHz is certainly fast and the logic we have is massive.

Altera says unpredictable behaviour in hardware without telling as what sort of behaviour. I will certainly go for dual port ram without grey counter or clock crossing.

--------------------------------------- Posted through

formatting link

Reply to
kaz

Hello,

Am Donnerstag, 13. August 2015 23:40:39 UTC+2 schrieb kaz:

I have no experience with Altera, but remember long time ago a "bug" for Xi linx with RAM, where I heard this was in fact related to weakness in test r outines to identify production failures. Microsemi had also ~2 years ago so me RAM related issues were I believer long routing of signals addressing RA M was not correct annotated which might lead to STA say clean, but real tim ing was not clean.

I had once a problem with a design, which behaved in rare cases in field st range while lab showed long time no problem and it took very long to track the error to an bug in external USB software, I know therefore how nasty it is to proove over and over again, that fpga internal timing is fine for ev ery clock crossing.

regards Thomas

Reply to
Thomas Stanka

.

What version of Quartus are you using? The one link says it applies only t o 11.1 with a fix starting with 11.1 SP1. The other link does not specify a software version number but the report is dated just over one month ago w hich suggests that the problem has resurfaced. Your best bet then would be get on Altera to see what the latest word is on a fix here

I see no mention of that

ing. This doesn't make much sense...but anyway, it appears that there is anecdot al evidence of a problem with applying timing constraints that can cause th e fifo you are using to fail so you're likely getting to the root cause.

Kevin Jennings

Reply to
KJ

What version of Quartus are you using? The one report is specific to only 11.1 with a fix in 11.1 SP1. The other report is from a bit over a month ago and doesn't link it to a specific version but obviously the problem seems to have resurfaced.

No it doesn't

This makes no sense...but in any case you now have anecdotal evidence of how incorrect timing constraints can result in a failure of the fifo that you are using so you are likely close to a solution.

Kevin Jennings

Reply to
KJ

is

only

month

logic

here is the copy/paste from second link

The probability of a hardware failures increases as the logic utilization and DCFIFO clock rates increase.

--------------------------------------- Posted through

formatting link

Reply to
kaz

Kevin,

I will be interested to see why it doesn't make sense. Though wr/rd clocks are asynchronous but write rate = read rate regularly. I don't need to worry about pointer/flag crossing. fifo is 16 words deep. I wait till it is half full and start reading non stop each side running its own address generated in its clock domain. It should have been dual port ram only in the first place.

--------------------------------------- Posted through

formatting link

Reply to
kaz

"...without grey counter or clock crossing" didn't make much sense since yo u still have two clocks and there will still be clock domain crossings. Th ose crossings will just occur between domains where there is a specified ph ase relationship which does open up alternative solutions over situations w here you don't have such a relationship. It's not worth belaboring here, s ounds like you know what you want to implement.

Kevin

Reply to
KJ

I'm not clear on how a clock domain crossing can have any timing restrictions. Clock domain crossings can be between async clocks which can have any phase relationship on any clock edge, varying with each cycle. So how can you possibly apply timing constraints to that?

--

Rick
Reply to
rickman

e you still have two clocks and there will still be clock domain crossings. Those crossings will just occur between domains where there is a specifie d phase relationship which does open up alternative solutions over situatio ns where you don't have such a relationship. It's not worth belaboring her e, sounds like you know what you want to implement.

Kaz's earlier posts indicated that the two clocks in question had a fixed p hase relationship so he was going to try to take advantage of that in some fashion. So there are still multiple clock domains, therefore there are cr ossings but the two clocks are not truly asynchronous (unless Kaz has been holding back on his description of the clocks).

If the clocks truly have a fixed phase relationship, then a failure that wo uld occur only one in a bazillion lifetimes if the clocks had been asynchro nous could tend to show up much more frequently since the failing timing pa ths could be way more likely to be occurring on almost every clock cycle, n ot just when the clock phases drifted into just the wrong alignment.

Kevin

Reply to
KJ

Fifo or SDRAM?

It turned out to be the fifo. Data captured directly from fifo input/output showed that the problem is from the suspected fifo. It must be some sort of fifo ip internal failure of obscure nature. The issue also disappeared by reseting this fifo (using dedicated reset that does not reset anything else). The chosen remedy is to apply this reset immediately before any capture rather than redsign a fifo.

There are many fifos in our design but only this one showed failure.

Thanks for all your contributions.

Kaz

--------------------------------------- Posted through

formatting link

Reply to
kaz

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.