aurora reliability

All

Does anyone have a feel for how robust aurora is?

I have worked out a packet based protocol to put on top of aurora which will re-send packets which are corrupt at the receiver but what is the chances of the aurora system itself falling over?

Katherine

Reply to
katherine
Loading thread data ...

That is really a signal integrity issue. If you get errors, then you need to investigate where the signal intergrity problems are (of course after you verify that you are not using the Aurora interface incorrectly). I have run many GBytes through the links without any errors.

Reply to
Duane Clark

Our experience is that you are basically right. But the markets perception is that there is a bit error rate for any MGT link. Xilinx have XAPP762 to help there customers measure it!

We recently added hamming codes to a system but it has proved untestable (no errors yet!).

But I still have to assume that there will be some in the life of the product.

So I need to know whether once the Aurora is working, with channel up at both ends, Aurora can cope with an error on the comma K characters it is using.

Katherine.

Duane Clark wrote:

Reply to
katherine

Katherine,

A properly designed link using any Xilinx MGT has 0 errors.

That is how they are supposed to work.

If you are running at some fixed, but small dribbling error rate, the link is broken, or not designed properly.

As soon as you near the edge of the error rate curve ('waterfall curve', anything can then cause you to fall over into the 1E-3 region: inoperable (temperature, voltage, etc.)

Again, properly designed and implemented links have NO errors.

Having a small but dribbling constant error rate is evidence of a bad link, or a badly designed link (too much loss, for example).

That is why when EDN magazine asked Xilinx for the MGT error rate, it was stated as 0.

Just because the specification for a standard is 1E-12, is no reason to do sloppy engineering.

Austin

kather> Our experience is that you are basically right.

Reply to
Austin Lesea

Until somone fires up an arc welder in the vicinity :-) Anything that can go wrong will - it depends on the requirements of the system as to whether errors of that sort are acceptable. And then to come up with whatever mitigation is required. For example a directly-life-and-limb threatening system will probably not use a single link of any sort over any distance!

Sorry to sound tedious, but categoric statements with zeroes in them tend to wind the pessimist-in-me up!

Or am I missing something in the MGT implementation - I have to admit to only being aware of them, not having used them - our car applications tend to stick around lower bitrates (well, apart from the video cameras!)

Cheers, Martin

--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt
Reply to
Martin Thompson

The design is for the embedded market. I have no idea at all what firmware is going into the V2Pro nor at what frequency. The decoupling, for instance, is not matched to any particular frequency nor are the power supplies matched for any particular transient load. Had a hell of a time recently with a hotswap controller which was in full production and then a customer enables his clocks, the FPGA gulps current and down went the board untill the next power cycle.

I also have no control over the backplane, nor the gigabit router that some of the MGTs are driving

etc, etc, etc.

Two years ago Xilinx were very very cagey and wanted to hold everyones hand through MGTs with very strict guidelines. Now with 10GBps MGTs woking on FR4 the tune seems to have changed!

Reply to
katherine

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.