fifo or sdram bug?

[kaz]

The fifo is not home grown. It is altera fifo core. We never discard wel
tried cores for home made work.

DC fifo is built by Altera around dual ram but if (as in my case) th
clock rates are predictable then one can control wr/rd pointers each i
their clock domain without having to cross clock domains thus reducin
risk and resource. That is my point and is well known desig
recommendation.

The fifo in question is just 32 bit wide dc fifo from altera core wit
internal pipe set to 3, rd/wr protected, connected to clk 368.64 at writ
side enabled 2/3 and connected to 245.76 on the read side always enabled
Initially the read
enable is delayed to wait for few words (even though it is protected).

Timing is clean. I imagine the write pointer is working but the rea
pointer is toggling between 0 and 15 with two clock delays leading t
samples 0,17,2,19 ...etc. Just a guess.

I have put a ram to capture few data from this fifo in the field whe
problem occurs and I am awaiting results
--------------------------------------
Posted through http://www.FPGARelated.com

 

[kaz]

Thanks Thomas. These two links could explain it well though my quartus i
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 logi
size. Our speed of 368.64/245.76MHz is certainly fast and the logic w
have is massive.

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

--------------------------------------
Posted through http://www.FPGARelated.com

 

[Thomas Stanka]

Hello,

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

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.

I have no experience with Altera, but remember long time ago a "bug" for Xilinx with RAM, where I heard this was in fact related to weakness in test routines to identify production failures. Microsemi had also ~2 years ago some RAM related issues were I believer long routing of signals addressing RAM was not correct annotated which might lead to STA say clean, but real timing was not clean.

I had once a problem with a design, which behaved in rare cases in field strange 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 every clock crossing.

regards Thomas

 

[KJ]

On Thursday, August 13, 2015 at 5:40:39 PM UTC-4, kaz wrote:

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

What version of Quartus are you using? The one link says it applies only to 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 which 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

The link says the possibility of failure increases with speed and logic
size.

I see no mention of that

I will certainly go for dual port ram without grey counter or clock crossing.
This doesn't make much sense...but anyway, it appears that there is anecdotal evidence of a problem with applying timing constraints that can cause the fifo you are using to fail so you're likely getting to the root cause.

Kevin Jennings

 

[KJ]

On Thursday, August 13, 2015 at 5:40:39 PM UTC-4, kaz wrote:

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.

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.

The link says the possibility of failure increases with speed and logic
size.

No it doesn't

> I will certainly go for dual port ram without grey counter or clock crossing.

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

 

[KJ]

On Friday, August 14, 2015 at 9:17:56 AM UTC-4, kaz wrote:

I will be interested to see why it doesn't make sense.

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

Kevin

 

[kaz]

On Thursday, August 13, 2015 at 5:40:39 PM UTC-4, kaz wrote:
Thanks Thomas. These two links could explain it well though my quartu
is
older version but I assume Altera have bug in reporting their bug as
well.

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

The link says the possibility of failure increases with speed an
logic
size.

No it doesn't

here is the copy/paste from second link

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

--------------------------------------
Posted through http://www.FPGARelated.com

 

[kaz]

I will certainly go for dual port ram without grey counter or clock
crossing.

This makes no sense...

Kevin Jennings

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 runnin
its own address generated in its clock domain. It should have been dua
port ram only in the first place.

--------------------------------------
Posted through http://www.FPGARelated.com

 

[rickman]

On 8/14/2015 9:58 AM, KJ wrote:

On Friday, August 14, 2015 at 9:17:56 AM UTC-4, kaz wrote:

I will be interested to see why it doesn't make sense.

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

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

 

[KJ]

On Friday, August 14, 2015 at 1:32:02 PM UTC-4, rickman wrote:

On 8/14/2015 9:58 AM, KJ wrote:
On Friday, August 14, 2015 at 9:17:56 AM UTC-4, kaz wrote:

I will be interested to see why it doesn't make sense.

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

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?

Kaz's earlier posts indicated that the two clocks in question had a fixed phase 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 crossings 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 would occur only one in a bazillion lifetimes if the clocks had been asynchronous could tend to show up much more frequently since the failing timing paths could be way more likely to be occurring on almost every clock cycle, not just when the clock phases drifted into just the wrong alignment.

Kevin

 

[kaz]

Fifo or SDRAM?

It turned out to be the fifo. Data captured directly from fif
input/output showed that the problem is from the suspected fifo. It mus
be some sort of fifo ip internal failure of obscure nature. The issue als
disappeared by reseting this fifo (using dedicated reset that does no
reset anything else). The chosen remedy is to apply this reset immediatel
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 http://www.FPGARelated.com