04-19-2013 07:36 AM
I have asked the case be escalated on your behalf.
You could have asked for escalation yourself.
I will let you know if I hear anything.
04-21-2013 04:59 PM
Could you confirm that the Zync actually implements ECC and not just Parity Error detection?
The TRM says the Zynq implements an ARM cortex-A9 but looking at the ARM TRM shows only the A8 with an ECC option where as the A9 only has Parity error dection.
- see Section "8.7 Parity and error correction code" - says it can be implemented with ECC support.
So if the Zynq does support it perhaps this is a Xilinx enhancement, which would mean the ARM guys are not going to
be helpful, you would really need to talk with an internal engineer.
04-22-2013 07:06 PM
Thanks - I think that ECC is Xilinx addition.
If you interested I added a suggestion to the Web Case of how the ECC could be tested once we get the ECC error stats register incrementing. Jangi has raised some sort of CR against it so perhaps we might get this working.
04-23-2013 04:01 PM
Jangi on the Web case they are looking at building some code to test this - will keep posted if they
make a break through - which would be great for me.
04-30-2013 04:19 PM
From the Web case I understand there is an issue and they suggest closing the Web case and waiting for the CR.
Unfortunately I still don't know any details of what the CR is - software/hardware/configuration/???
Perhaps they think I know or perhaps it's secret - I have asked perhaps I might be lucky and be told something to help me ... one day... :-(
05-01-2013 07:26 AM
Request that it be escalated. Tell them you need an answer. You are the customer, and you are always right. If you let them close it, they are "off the hook."
There are no "secrets," if it is broken, we have to post an errata, and tell folks when it will be fixed.
I will ping some folks again. It should not be this difficult to use an error counter....
05-01-2013 09:39 AM
I am being told this works. An example with code is something you have requested from support, and that may be what is taking the time. There is no technical issue that anyone is aware of (among the folks who know -- i.e. the designers/verifiers).
05-01-2013 11:17 PM
Thanks for this Austin, I only just noticed your reply (was expecting a web case response first).
I will have to look at this next week.
I think I am missing a key part of the puzzle - likely this distinction between reads from one CPU versus another or probably something to do with the L2 cache (which has another ECC level) getting in the way or something.
Perhaps disabling the L2 cache could avoid the issue. Not sure how to read from one CPU versus another via the kernel (runs both CPUs) or uboot (only runs one CPU) .
05-02-2013 07:25 AM
Stay tuned! It appears that all my questions about this may have uncovered an issue! They are now really looking at it in the design team (the folks responsible for the design). Seems they were convinced it had all been checked out (box checked in the verification spreadsheet as 'done'). But, when they go to look at exactly what was checked out, they try to repeat it, and it doesn't work....
So, I stand by everything I have already posted (as they have told me that is how you do it). Now it is a questions of them doing it again, and telling us how they did it.
And, do not let the webcase folks off the hook, either.