PYNQ: PYTHON PRODUCTIVITY

Using mutex (or lock) in Microblaze?

Hello,

I am using a Pynq Z2 with the last version of Pynq on it (v2.5), and the default bitstream in a jupyter notebook. I am getting data with a spi communication from another device, and in order to do that, I am using the arduino header with Microblaze (and the spi.h lib). My communication is working and it is not the problem. To transfer the data to the python notebook, I’m sharing a buffer (like the one shown as an example in the microblaze_programming notebook), and the microblaze code section is writing the data in it.

To give some instruction to the microblaze part, like transferring a flag, I created another buffer that is frequently read by the microblaze code, and that can be written by the python code. The problem is : what happen if both actions are at the same time? Because I don’t want to have any crash problem, I wanted to use some mutex, or any kind of lock. This way I could be sure that the microblaze code section and the python code won’t access the same data at the same time. The lock can be implemented only in the microblaze magic cell, because I can call the function from the python interpreter.

In other words, my question is : Is there any way to implement a mutex, a semaphore, or any kind of lock in the microblaze magic cell (I’ve tried to include the mutex.h lib but it’s not present in the pynq image and I don’t know where and how to install it). And eventually, is there a way to lock the data from the python interpreter?

Thank you for your time.

This is an interesting challenge. There is at present no way to common locking mechanism between the Microblaze and the Python and there are potentially even more issues you need to consider.

The Microblaze’s memory is a true dual-ported RAM which means it’s possible for a writes and reads from both Python and Microblaze to hit the RAM on the same cycle which results in undefined values being read/written.

We worked around this for the IPython Microblaze communication channels by having the control memory locations only be accessed in a single direction - i.e. one 4-byte word that was only written from Python and one 4-byte word that was only written from the Microblaze. The values of the two registers then form two exclusive regions in the rest of the communication buffer so that the same byte is never written two simultaneously. To avoid problems with read/write conflicts we always read the status words twice and only act when the value is stable. This means a single-cycle collision can be detected and ignored.

For your case, you’ll probably need to implement something similar. You can have a look at the Python and C implementations of our stream to see if that helps with designing a lock implementation.

Peter

2 Likes

Thank you for your answer, I’ll look into that to see if it can work.

Nicolas