Eyescan on Custom PXIe 6593 Code (8b/10b encoding)

[Intaris]

We are trying to implement an FPGA code to perform an Eye-scan of our MGT link. We are trying to modify the code found under the following link for our tests:
https://forums.ni.com/t5/Example-Code/Using-Eye-Scan-with-PXIe-6593-and-PXIe-6594-High-Speed-Serial/...

I have just found the following link: https://www.ni.com/docs/en-US/bundle/using-eye-scan-flexrio-high-speed-serial/page/configure-eyescan... but am still a bit unsure as to which VIs are on the host, and which are on the FPGA.....

We can get the standard KU40 bitfile to work and it produces an eye-scan as expected, but when we implement the DRP ports in our custom CLIP and compile, we get an error when trying to execute the eye-scan. The code we are trying to utilise is intially designed for a 64b/66b encoding example, not sure if that's relevant as the Eyescan functionality is kind of protocol-independent AFAIK.

Error -52007 occurred at niInstr FIFO Register Bus v1 Host.lvclass:Write Array.vi:440001

Possible reason(s):
The requested operation did not complete in time.
Complete call chain:
     niInstr FIFO Register Bus v1 Host.lvclass:Write Array.vi:440001
     niInstr FIFO Register Bus v1 Host.lvclass:Write.vi:2270001
     niInstr Instruction Target v1 Host.lvclass:Context Write.vi:1900001
     niHighSpeedSerial Eye Scan Single Point (GTHE3) v1 Host.lvclass:Write Qual and SData Masks.vi:7420001
     niHighSpeedSerial Eye Scan Single Point (GTHE3) v1 Host.lvclass:State Machine.vi:6050001
     niHighSpeedSerial Eye Scan Single Point (GTHE3) v1 Host.lvclass:Initialize.vi:5890001
     niHighSpeedSerial Eye Scan v1 Host.lvclass:State Machine.vi:6050001
     niHighSpeedSerial Eye Scan v1 Host.lvclass:Start.vi:1880001
     niHighSpeedSerial Rectangular Eye Scan v1 Host.lvclass:Start.vi:1880001
     Aurora Stream (NI 6593) (Host).lvlib:Acquire Eye Scan (Host).vi

Does anyone have any pointers? Is this a problem with our DRP-implementation in our CLIP? Is there anything special we need to take care of?

This is the VI in which the error occurs - due to the nature of the code, it's difficult to tell what's going wrong.

This is where, in the overall scheme of things, the error is occurring. I would think the DRP interface seems to be working, but maybe this is the first portion of the overall codepath which actually uses the DRP interface?

Any help is appreciated.

[UMASO]

Hello, I would recommend to learn basics of Instruction Framework which handles the communication between host and FPGA in the example.  

https://forums.ni.com/t5/NI-Labs-Toolkits/Instruction-Framework-Tutorial/ta-p/3533500

Error -52007 may occur, when values are written to FPGA through Register Bus, but the write complete event is not returned within a specified amount of time.  I am not familiar with what is implemented in Bus Interface of the custom example, but it worths to check a part of the Bus Interface.vi, where the error-related registers are handled.  

[Intaris]

Thanks for the reply, but my question is more on the FPGA-side of things.

We want to re-use a standard eye-scan VI which works fine with a standard FPGA bitfile from NI with our own custom FPGA code, but cannot get the eyescan functionality to work. Something on the FPGA is not working as required.

Specifically, the DRP interface to the MGTs on the target are our issue. My question is meant more on the CLIP-side of things within the FPGA. We have registered the DRP interface from our CLIP with the instruction framework and implemented the code as used int he NI examples, but when we try to run the code, it doesn't seem to work.

We're comparing our CLIP AXI-DRP Bridge implementation with that from the NI example and just cannot find any significant differences.

[UMASO]

---

@Intaris wrote:

I have just found the following link: https://www.ni.com/docs/en-US/bundle/using-eye-scan-flexrio-high-speed-serial/page/configure-eyescan... but am still a bit unsure as to which VIs are on the host, and which are on the FPGA.....

From your statement above in your first post, I thought you did not know much about the framework.  That is why I pointed to the tutorial of Instruction Framework.  If you are familiar with it, you may be able to track the source of error down to what occurs in the CLIP.  One of the resources in the CLIP resource may be referred as a source of write complete signal for the register access through register bus.  Once the resource which prevents write complete from being asserted is identified, you may be able to debug what is not working inside your CLIP.  

[Intaris]

I have since found a couple of promising leads, but exporting the LV example from Vivado and importing and synthesising in Vivado was required. There are some signals which are globally defined which must be routed to the GT Receiver core, but they are done internally in the portion of the code which NI only offers as a netlist. Fortunately, Vivado can import these and show what's going on in the background.

It's not really NIs fault, they are just using the Aurora 64b/66b IPCore, but how on earth is anyone supposed to know that these signals need to be routed from the top-level LV VI to the CLIP without any kind of documentation or code where the signals appear on the interface.

One thing is sure, learning how to use Vivado is becoming more and more neccessary. Luckily, the version included in LV FPGA is not handicapped to such an extent that it is unusable.

[UMASO]

NI has well put skill levels required to handle High Speed Serial Interface since they released first HSSI devices.   

https://www.ni.com/ja-jp/shop/electronic-test-instrumentation/digital-instruments/an-introduction-to...

[Intaris]

That's lovely marketing, but when basic documentation for the individual FPGA targets are missing (such as which FPGA-MGTs are routed where on the QSFP+ Connector) then it makes life difficult. We've been in touch with some extremely competent and helpful people from NI on this issue since more than a year, and they themselves admit that the outward-facing documentation is incredibly lacking in detail.

The fact that we need VHDL abilities to adapt VHDL code is not surprising. But some information as to how the board is connected, which clocks from within the Flex-RIO API are for what and such things are hard to find if you don't have documentation. Some of this has since been published, but quite a bit is still missing. Some things which are essential to interfacing with our target have been released literally one or two weeks ago.

For a card which has been sold for a few years.

[UMASO]

Anyways, did you resolve your problem?  What documentation was lacking for you for which part of the example?  How did you resolve your issue?   Which signals were globally defined and routed to the receiver core, and which of them are hard to tell that these should be connected to Top-level LV VI?   Those were not covered by Xilinx manual for Aurora 64b/66b IP?  Did you contact NI support?

Please share your experiences for other users.  Documentations are sometimes not enough not only for VHDL-related example, but also for any example codes.  

[Intaris]

Problem is as yet unresolved.

One example is, among many others, the fact that "PllClk80", an 80MHz clock, derived from the PXIe100 Clock is the same as "AxiClk". The assignment of one of these clocks to the other is performed within an encrypted VHD file, and I have never been able to find any kind of documentation on this anywhere. In addition, we suspect that the "s_aclk" on the top-level design is actually the same clock also.

Obviously, trying to implement code without knowing which clocks relate to which other clocks (or even which clocks names literally refer to the same clock) can be very confusing. There are several important things which are assigned outside of the files available for reading, only residing within the encrypted files. Without documentation to let us know what is actually going on, it's very difficult to plan accordingly.

And yes, we have been in contact with NI support for the last year. Progress is extremely slow.

[UMASO]

I am asking if you resolved the error -52007 you asked in your first post.  

Are you still having the error?  Is that error related to all what you are complaining about the lack of documentation?