Re: PCIe-AS - Tutorial -- Is there a CRC for the address header ? [message #942 is a reply to message #933] |
Fri, 17 September 2004 15:52 |
David Slogsnat
Messages: 3 Registered: September 2004 Location: Mannheim University
|
occasional visitor |
From: *ra.informatik.uni-mannheim.de
|
|
Walter F.J. Müller wrote on Wed, 15 September 2004 18:15 |
That means, in ATOLL there is protection against single bit errors, not less, not more.
AS uses the PCIe physical link layer, which is serial with 8b/10b coding. The consequence is, that a single bit error on the medium will give in many cases an invalid code word, and will thus be detected, but in other cases, gives a different code word leading to multiple data bit errors. For examplefor the later case is that a single bit error in bit e can turn D0.1- into D9.1-, which when decoded gives a two bit error (two 0 are turned into 1). Since two bits are flipped, this isn't detected with a parity bit.
From this I'd conclude, that the ATOLL protection method actually doesn't protect against all single bit errors on the medium when a serial link with 8b/10b is used, thus a parity bit doesn't seem to be the prefect solution either.
|
The ATOLL protection method works very very fine for parallel links. And that is the link ATOLL has been designed to use (and it is the link that is used currently).
You are absolutely right that this method is not as good when used with 8b/10b coding over serial links. But since we don't even have such a system yet, I can't tell you from a practical standpoint wether it is sufficient or not....
Which leads us to another problem: what do you mean by a perfect solution (and what do I mean by sufficient) ?
There is always a trade-off between costs of error protection (in terms of additional delay, additional silicon, higher data redundancy...) and fault-tolerance. The level you want to have in the NIC hardware depends strongly on your needs, i.e. your application.
So as we are discussing this topic, an important question that should be answered beforehand is: what are actually the needs and requirements for our application?
|
|
|