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

[Intaris]

"Problem is as yet unresolved."

From my post above. Some issues have been located after a deep-dive in Vivado for things which should really be documented by NI. Fixes are ongoing, but while we're hopeful, a solution is not yet there.

Yes, it is related to the lack of documentation. Trying to fix errors with a serious lack of documentation is very much (literally) hit-and-miss. Fixing the errors would be a lot easier (or avoiding the errors altogether) would be much easier with suitable documentation.

[UMASO]

So, you are still having the error -52007, correct?  

If so, what have you done so far?  What do you mean by "a deep-dive in Vivado"? Did you do it for debugging the error -52007?  

Please explain about your progress of finding the reason of the error, so that people can better help you, which you may expect to get by posting on NI community.  Which files, which part of codes, which packages, have you handled so far?  

Below is community guideline and third one says "Stay on-topic".  

https://forums.ni.com/t5/Using-the-NI-Community/NI-Community-User-Guidelines/ta-p/3698591

If you find any critical missing of documentation, why not share your find on community to help others, or submit your suggestion to Idea Exchange?  

[Intaris]

---

@UMASO wrote:

So, you are still having the error -52007, correct?  

If so, what have you done so far?  What do you mean by "a deep-dive in Vivado"? Did you do it for debugging the error -52007?  

Please explain about your progress of finding the reason of the error, so that people can better help you, which you may expect to get by posting on NI community.  Which files, which part of codes, which packages, have you handled so far?  

Below is community guideline and third one says "Stay on-topic".  

https://forums.ni.com/t5/Using-the-NI-Community/NI-Community-User-Guidelines/ta-p/3698591

If you find any critical missing of documentation, why not share your find on community to help others, or submit your suggestion to Idea Exchange?  

---

I would still have the error if I tried running the eyescan code from NI, yes, but I haven't done that since locating some issues in our VHDL code and we are working on fixing those first. Only when those are fixed, will be again be able to recompile a bitfile to see if that has helped.

There are different topics here. One is that the eyescan code from NI is not very transparent as to which implementation it requires on the FPGA (this has since changed with documentation appearing in the last month on the topic) and since we can't see what the NI code is actually doing, it's hard to see at which point the process is breaking down. Having something in a DLL call return a timeout doesn't really narrow things down much, as we don't typically know which functions the DLL is calling in the background.

MY reference to a "deep-dive" in Vivado was following each and every connection from an exported project for NIs example and an exported project for our code and seeing where exactly the differences come from. We imported these projects into Vivado and synthesised the design there. This allowed us to view the schematics for ALL of what was going on in the FPGA code, including the functionality "hidden" by NI. It is here where we realised we were attributing different clocks (clocks which which were being attributed in password-protected encrypted VHDL files from NI. This issue would not have been possible to find out without Vivado since NI does not actually really document this.

When our search is finished, I will probably share a post outlining what we did. But that first requires having something worthwhile to post.

Also, while I appreciate you posting the forum guidelines for me, I've been using these forums for more than 20 years at this stage, I'm already quite aware how they work, thanks. On a counter-note, it would seem you are insunuating that some of my replies have been off-topic? Would you care to expand on this a little?

[UMASO]

---

@Intaris wrote:

---

On a counter-note, it would seem you are insunuating that some of my replies have been off-topic? Would you care to expand on this a little?

---

Please remember your first post.  You said

• a bit unsure as to which VIs are on the host, and which are on the FPGA.....
• 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
• Error -52007 occurred at niInstr FIFO Register Bus
• Is this a problem with our DRP-implementation in our CLIP? Is there anything special we need to take care of?
• due to the nature of the code, it's difficult to tell what's going wrong

You wanted to know why the error occurs and where the error stems from.  Also, you wanted to know the error occurs due to customization of the CLIP or not.  So, to stay on the topic, the goal of this thread is to find the root cause of the error, and to tell if that error is due to your customization or not.  

Debugging your customization of the CLIP or compalining about lack of documentation are outside of this scope.  

---

@Intaris wrote:

---

---

I would still have the error if I tried running the eyescan code from NI, yes, but I haven't done that since locating some issues in our VHDL code and we are working on fixing those first. Only when those are fixed, will be again be able to recompile a bitfile to see if that has helped.

There are different topics here. One is that the eyescan code from NI is not very transparent as to which implementation it requires on the FPGA (this has since changed with documentation appearing in the last month on the topic) and since we can't see what the NI code is actually doing, it's hard to see at which point the process is breaking down. Having something in a DLL call return a timeout doesn't really narrow things down much, as we don't typically know which functions the DLL is calling in the background.

Though the lowest-level of the register bus Host-side VIs call DLL, it accesses to specific registers on FPGA by address.  That is why I introduced you to the introduction of Instruction Framework in my first reply.  Have you taken a look at it?  If so, writing which address returns the error?  What address spaces are defined for the CLIP?  

[Intaris]

---

@UMASO wrote:

---

@Intaris wrote:

---

On a counter-note, it would seem you are insunuating that some of my replies have been off-topic? Would you care to expand on this a little?

---

Please remember your first post.  You said

• a bit unsure as to which VIs are on the host, and which are on the FPGA.....
• 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
• Error -52007 occurred at niInstr FIFO Register Bus
• Is this a problem with our DRP-implementation in our CLIP? Is there anything special we need to take care of?
• due to the nature of the code, it's difficult to tell what's going wrong

You wanted to know why the error occurs and where the error stems from.  Also, you wanted to know the error occurs due to customization of the CLIP or not.  So, to stay on the topic, the goal of this thread is to find the root cause of the error, and to tell if that error is due to your customization or not.  

Debugging your customization of the CLIP or compalining about lack of documentation are outside of this scope.  

I'm sorry, that's not off-topic at all. Where do you think the errors are if not within the CLIP? You might not see the connection, that's fine but everything I have posted in this thread is connected. Due to the need for a different CLIP (Due to a different MGT protocol), the need to re-create everything else needed for correct operation of the transceiver is very important. And exactly here, there are issues with the documentation of the device we are using. The problem is not the instruction framework, the problem is what is being controlled VIA the instruction framework. The instruction framework is a complete red herring here with respect to my problem.

My initial question was with regard to the Eyescan module (which uses the instruction framework) but I do not know if this is the only depency of the toolkit because the functionality is hidden behind a DLL node. You know what IS a dependency of the Eye-scan? Proper MGT implementation, including which aspects of the example implementation is required and which are optional.

Do you seriously think that in the in order to find out whether our customisation of a CLIP is a problem, debugging these customisations is not applicable? Finding out what exactly about the customisation of leading to the problems is, in your mind, not connected to the fact that the CLIP might be the problem? You might want to re-think that stance. I'll point it out more clearly how ridiculous your stance is.

You yourself state that my original question dealt with "why the error occurs and where it stems from". Well, for me personally answering the "where" with "CLIP" is simply not going to cut it. I could just as easily answer with "FPGA". Well, yes, that part is really obvious, but understanding precisely which aspect of it is the problem is important to me (and any serious developer) in order to be able to get it to work. I mean, why do you think I want to know where it it coming from? Hmm? Purely out of curiosity? No, it is to fix it. And everything in this post is part of the quest to do precisely that.

So I'd recommend you don't go around policing what you think other people meant by their own forum posts and policing their journey to finding a solution. If you want to ask questions abouit it, fine, people have different levels of expertise in different areas and sometimes don't phrase things in the same way another user might but your position of telling ME what the purpose of MY post is is just pretentious, sorry.

[UMASO]

I know you have not resolved your problem yet, but, at least for the purpose of this thread, you clearly did not even tell which VI resides on host or FPGA.  Without understanding the layers of LabVIEW, it is not possible to track down what is happnening in CLIP whether or not it is customized.  Then, why did you comment "a bit unsure as to which VIs are on the host, and which are on the FPGA....." with even pasting some images?  

Handling the entire of your debugging your own custom codes is not mentioned in your first post.  And even if it is mentioned in your first post, that may not be something people can help in a single thread.  

I just wanted to help you understanding through the layers, but you started talking about inside of CLIP and lack of documentation, as if you knew about the framework.  If you would have known about the framework, you had never asked such as question like which VIs are on the host and which are on the FPGA.  

---

@Intaris wrote:

---

I'll point it out more clearly how ridiculous your stance is.

---

Such words are not respectful.  I do not think you follow the guideline.  

And please do not pesronally send a message.  

[UMASO]

The instruction framework and register bus are simply interfaces. They serve the purpose of connecting the host PC and FPGA. If you understand their mechanisms, you can quickly determine where in the FPGA the errors occurring on the host PC are originating from.

Why the issue is happening on the FPGA side is a matter related to your FPGA and falls outside the scope of the initial question. "Stay on topic" means not straying away from the scope of the original question. You can start a separate thread to ask about details regarding VHDL or LabVIEW on the FPGA side. Alternatively, you can debug with Vivado on your own, continue seeking additional documentation from NI, as you have done before, or consider posting in the Idea Exchange for suggestions.

Expressing frustration about documentation or becoming overly emotional by sending personal emails is counterproductive.  You are currently aware that there were issues with your customization and are focusing on debugging it. You have made progress from a state where you didn't understand the relationship between the host PC and FPGA. I am happy about that. You should recognize the contradiction within yourself. That's why you became emotional – because you're aware of the contradiction yet continue to make excuses.

Being a part of the community for 20 years doesn't necessarily mean adhering to the guidelines. I recommend reviewing them carefully once again.