cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
marco.vogt
Visitor
Visitor
391 Views
Registered: ‎05-22-2018

Aurora 64b66b idle frames and polarity check

Hello,

we are currently struggling with the Aurora 64b66b IP core. Let me first give you an overview:

The transmitter in our case is a custom designed ASIC. We have prototype chips and a simulation environment. With the 2016 Version of the Aurora 64B66B IP core, everything works as expected - in simulation and on actual hardware. Now we are struggling with the 2020 Version.

The core is generated from an xci file and we use it with our own implementation of the support module. So basically we instantiate the Aurora core module and add reset and clocking resources specific to our needs.

What we now observe is, that the receiver is not locking anymore due to the polarity checker module not releasing the HLD_POLARITY_OUT signal. Compared to 2016, it is now much more sophisticated and checks not only the header but the full frames.

Now the issue: The idle frames sent by our chip have the right header, but carry additional debugging information in the last two bytes. According to SP011 (v1.2) p. 41 only the header seems to be relevant, while the rest of the frame is marked as "-" which we interpret as "don't care". But in our observation, the polarity checker cares about every single bit.

At this point we can fix it by changing the idle frames to be all 0 after the header (confirmed to work in simulation) but the designers would like to keep it like it is now. Because the firmware is generated by a tcl script and the IP cores are automatically generated from their xci files, patching the polarity checker manually after the IP core creation is possible but tedious.

Did you run into those issues or do you have a suggestion? Would be very appreciated.

Best regards

0 Kudos
1 Reply
marco.vogt
Visitor
Visitor
284 Views
Registered: ‎05-22-2018

Any ideas would be very much appreciated.

0 Kudos