Zybo Z7 board has different response if using PS-PL communication

[NotMyCupOfTea]

Dear All,

"I'm working with Vivado 2018.3 and a Zybo Z7020 board"

I write here because I have a very strange problem in a project that I have been developing in the past months.

Namely, I've been writing a verilog code to run on a Z7020 board. This code takes user input as parameters (that are hence hard-coded) and everything works fine with this project (no errors or not understandable warnings...)

Now, my job is to make sure that these so-colled parameters can be changed through a serial connection from a laptop. Hence, I've packaged my module in an IP and connected it to the PS, programmed the SDK and here is the problem : Many things work but some don't.

At the beginning, I thought that the SDK used a different convention to represent signed integers (two complement, only first bit changed...) and have thereby checked that the parameters sent by the SDK where equal to hard coded values in the PL... and they are! Every single bit..

I'm now out of option to understand my problem... Has anyone had similar issues in the passt? Does anyone have a clue for me?

Thank you a lot,

 

P.S. : Please do not hesitate to write a comment if you need any further infos.

[zygot]

3 hours ago, NotMyCupOfTea said:

Hence, I've packaged my module in an IP and connected it to the PS, programmed the SDK and here is the problem : Many things work but some don't.

This really isn't very informative to anyone trying to understand your problem.

[NotMyCupOfTea]

On 10/28/2019 at 5:12 PM, zygot said:

This really isn't very informative to anyone trying to understand your problem.

True, I'm sorry...

The project is meant to control Galvanometric mirrors to swipe a laser for a OCT microscopy system.

These mirrors can be oriented in space by applying a voltage to their poles and by this means orient the laser beam where needed to proceed for the imaging.

Now, acquiring an image requires to move the laser beam over the surface you want to acquire (for instance following the coordinates (0,0) - (0,1) - (0,2) ... (0,M) - (1,0) - (1,1) ... - (M,N)).

The output is then rescaled and sent to a DAC. Please see attached file to see what it looks like (please note that here the green chanel is the x and yellow chanel is y, with M = 5 and N = 3) .

Now the user must be able to set some parameters such as the number of steps on the x and y axis (M and N above), the position of the centre, the rotation angle around the centre... and this in real time. (For instance, imaging a living micro-organism can require to shift the centre fairly quickly).

This is the reason why the code has been packaged into an IP and connected to a laptop using a serial port and a bare metal application.

What happens then is that all the parameters are read correctly (number of steps, sine and cosine of the rotation angle, centre position...) but the result is different (see second caption below where M = 10 and N = 5).

There is to notice that the x and y commands are evolving in the wrong direction, that the output voltage range is 10 times smaller and (not in this case but other tests) that the x and y axis are not correctly placed one in respect to the other.

I will finish underlining that when the UART communication is not enabled, everything works fine.

I have also tried to enable the UART comunication without sending parameters (I still used hard coded parameters) and it didn't work either. I'm starting to think that there is a compilation error when adding the UAART...

I hope this helps a little bit more.

Thank you for your answer

 

 

[zygot]

1 hour ago, NotMyCupOfTea said:

I'm starting to think that there is a compilation error when adding the UAART...

Well, we can definitely rule that out. If you are using the PS UART there's nothing to compile. Of course you must have added some means in your board design to transfer the PS UART data to the PL and modify your logic registers; and that could be an issue.

When having multiple hardware build exports it's easy to get confused as to which one is being used by the SDK. That's the only idea I have for why it appears that using the UART but not changing the PL hard coded values give different results than not having a UART in your board design.

A typical issue for those not used to dealing with it is endianness. Specifically, the order of bits from msb to lsb. Often, a microprocessor uses a different bit order than standard IEEE HDL conventions. What you describe certainly sounds like that could be a possibility. This is hard to detect as reading back a value written to a std_logic_vector will not work. I've posted in the Project Vault the UartDebugger project code. You can add that to your PL logic to print out the value of the actual std_logic_vector, in the correct HDL bit order,  that has been written to using your PS UART. You'll need to assign two spare GPIO pins as RxD and TxD and use a separate 3.3V compatible TTL USB UART cable or breakout module for the UARTDebugger UART. I find such tools to be invaluable. If you use Verilog or don't like the UARTDebugger there are other options with similar functionality available in the Project Vault submitted by other people. Of course mine's the best ( for me )

.

[NotMyCupOfTea]

Hi Zygot,

Thank you for your answer!

However, I don't think the problem comes from endianness... As you can notice on the pictures of the previous post, the number of steps M and N are correctly transmitted to the board. Now I mght be wrong but I would expect a endianness problem to affect all the values sent between the PS and PL.

Furthermore, I've also tested to compile a project where the PS is included but "not working". meaning that the parameters remained hard coded in the PL. and it also doesn't work.

So I would think that the problem doesn't come from the communication PS-PL but from the PL itself...

You'll find in the attached files the following codes :

- The source codes and constraint file for the project "Galvo_cleaning"

- The source codes, constraint files and SDK C code for the project "Galvo_packaging" and a pdf explaining how I package everything (maybe this is the issue...)

- An Arduino code that outputs A_clock and ext_B_clk (see source code)

Please note that you'll need 2 pmod DA3 and a Zybo Z7020 board to run this code

 

I hope this can help to understand the problem further,

Thanks a lot

 

Sharing.zip

[zygot]

4 hours ago, NotMyCupOfTea said:

So I would think that the problem doesn't come from the communication PS-PL but from the PL itself...

What better reason than that to instrument your PL code, as I've suggested? I can help you figure out how to debug your code; I don't have the hardware or time to do it for you.

[NotMyCupOfTea]

Dear Zygot,

Thank you for your answer.

I didn't mean to upset you but as I have already tested for endianness and am using verilog, I wonder wheter the procedure you described allows to test something else.

On top of that, I have been working on FPGA for only 4 months and am still very unexperienced ==> i.e. I was not able to implement your suggestion and have no one near by who can help me understanding what you wrote. This is why I share the code.

Now, the question was what other problem can we think of.

Thanks for your help,

[zygot]

1 hour ago, NotMyCupOfTea said:

I didn't mean to upset you

No, no no... nothing about this thread is upsetting or irritating. Clearly, you are in deeper water than you should be. I do find that to be a bit frustrating, though not as much as you are likely feeling. Unfortunately, FPGA vendors, understanding how complicated their tools and the basic development flow is, see packaging everything into a GUI point and click user experience as a solution. If you are trying to create a limited design using nothing but their IP you can (sometimes) get quick results; but then if something goes wrong or you try and do something outside the coloring book you can get overwhelmed very quickly without an idea of how to proceed. That's not your fault.

Unfortunately, the ARM based FPGA device are seen by those with very limited experience as a safe and easy way to do FPGA development. Actually, it's more complicated. Your project would probably be a lot simpler using a straight HDL design on a regular FPGA target. Probably, an FPGA isn't the best choice for this project. But here we are.  One option is to re-evaluate your choice in platforms and start over. The other is to plug ahead and develop the skills required to achieve success. Assuming that you will choose the latter, where do you go from here?

I'm sure that this will get push-back but my view is that understanding an HDL, the development tools, and basic FPGA concepts isn't what's going to get anyone to where they are competent as FPGA developers. What people need is to be self-sufficient. What makes people self-sufficient is the ability to figure out how to debug designs that don't work as intended. Yes you need to other stuff to be able to trouble shoot problems but those things aren't sufficient. You've already reached the conclusion that your Verilog skills are not sufficient to work out a plan for instrumenting and debugging your design. That will have to be addressed. It's likely that your understanding of the tools could be better as well.

Do let's put aside the question of endianess, or even what might be the problem with what you have so far.

You probably won't like this advice but I think that it's the best that I can think of. Get a cheap FPGA board like the ARTY A7 or similar board having an FPGA without an ARM processor. Forget about even using a processor in your implementation. With an all Verilog design the development flow is a lot easier and you have more options for debugging ( well at least they are less complicated ). Learn how to write a testbench so that you can simulate your HDL. If you don't have experience simulating HDL you aren't ready to do conventional FPGA development much less ARM PS-PL development. Learn how to instantiate ILA and VIO IP into your simulated code to verify that what you are writing to internal registers is what you think is being written. These are basic vendor debug tools and sometimes are the best option for even experiences developers with a lot of home-brewed debug tools of their own. Use a UART for user input. Learn how to add a second UART for debugging purposes. Even if you don't want to use VHDL the project that I've posted for this has a testbench so you can at least use it to explore what's happening using the Vivado simulation tool. You can instantiate VHDL into your Verilog code and visa versa. I realize that what I'm suggesting looks like going backward. It only looks that way because you have an unrealistic view of where you are based on all of the work you've done so far. If you take this advice you will have a series of manageable, incremental, and smaller goals to achieve; and over time develop the skills allowing you to do what you set out to do originally.