• 0
vvk

Inter core communication

Question

 Hi, I am attempting to have the two ARM cores in  ZedBoard xc7z020 interact with one another via fpga (PL)core. Can anyone please  give the valuable suggestion on the way to proceed to this task.I need to take the random data from PS_Core0 and put it on fpga and from fpga this has to go to PS_core1 of Zynq 7020 SOC.

Share this post


Link to post
Share on other sites

8 answers to this question

Recommended Posts

  • 0

Hello,

Have you tried out the other solutions and other paths of actions that have been suggested to you on your other threads? How has that been going for you?

Thanks,
JColvin

Share this post


Link to post
Share on other sites
  • 0

Ever thought about building an AXI bus peripheral that either processor on the Zynq might use?  Something that sits in the physical address map that does ... whatever.  One example might be to create a shared memory peripheral.  Shared memory is well discussed and understood within computer science, so it shouldn't be too hard to figure out how to use it properly between two processors.

Dan

Share this post


Link to post
Share on other sites
  • 0
On 1/4/2017 at 10:35 PM, JColvin said:

Hello,

Have you tried out the other solutions and other paths of actions that have been suggested to you on your other threads? How has that been going for you?

Thanks,
JColvin

Hi,

I tried with the Zynq speed ways  labs on dual cores communication and it is working fine. I did not understood the concept of onchip memory communication and the usage of semaphores(SEM). can u once briefly the usage of these functions in the  software code.

Share this post


Link to post
Share on other sites
  • 0
On 1/4/2017 at 10:46 PM, D@n said:

Ever thought about building an AXI bus peripheral that either processor on the Zynq might use?  Something that sits in the physical address map that does ... whatever.  One example might be to create a shared memory peripheral.  Shared memory is well discussed and understood within computer science, so it shouldn't be too hard to figure out how to use it properly between two processors.

Dan

Hi ,

My doubt is instead of using shared memory for dual core communication and some functions ,cant we divide the entire ddr memory in 2 parts ie some part of the memory for core0 and the rest for core1? Is it possible to communicate between two cores by doing as mentioned earlier? if not,can u please briefly discuss the reasons behind it.

Share this post


Link to post
Share on other sites
  • 0

@vvk,

Actually, I was thinking more about doing this with block RAM--it makes for the simplest test case.

Here was my basic idea: if you place something on the peripheral bus, you should be able to read it by both CPU's, right?  The easiest thing to place off of the peripheral bus is block RAM.  Hence ... my post above.

As far as semaphores go, if you are hoping to complete this project and don't know what semaphores are, then I would *highly* recommend you take a moment to learn.  They are a very valuable concept--especially when trying to do things across multiple CPUs.

My current knowledge of semaphores comes from the semaphores section (2.4) of Dr. Jurgen Sauermann's treatise on "Realtime Operating Systems: Concepts and Implementation of Microkernels for Embedded Systems."  I found my copy as part of his C16 project on OpenCores, although ... I can't seem to pull it up right now.  Perhaps this site is down (again)?

The basic idea of semaphores is this: you have a number of finite resources (often only one).  This number is represented by an integer in your code.  There are two operations on these resources: to take one, and to put one back.  If it weren't for the multiple CPUs, or the multiple threads, or whatever, taking a resource would be as simple as decrementing the integer, and returning them would be as simple as incrementing the integer.

Where things get interesting is with multiple threads/CPUs.  In that case, when you attempt to take a semaphore, if the semaphore is there (i.e. the integer is greater than zero, some resources are available for you to grab), then the integer is decremented and your routine is marked as the owner of the semaphore--but nothing more.  If the semaphore isn't there is the interesting case.  In that case, your task/thread is suspended--that is, it's removed from the processors list of tasks ready to run.  Then, when the routine owning the semaphore returns, it sees your first task/thread waiting, and it releases it so that it can take the semaphore.  From the standpoint of your code, all you do is call a routine to get_the_semaphore() or another routine to put_the_semaphore() back.  You also have to be very careful to return any semaphores you grab, and to grab them in a way that avoids deadlocks--but I'll leave that discussion for another day.

I find the "banking/ATM" example is the easiest to understand, but ... lest someone who knows how these things actually work speaks up, I'll state up front that this is probably not how they actually work.  Imagine what would happen if two users tried to go to the bank/ATM to access your account at the same time.  Perhaps one user is you and another your significant other, perhaps you are one and the other is your employer, whatever.  The first user reads how much money is in the account: $500.  The first task is then suspended and the second task reads how much money is in the account: $500.  The second user adds your paycheck, $1500, to the account and writes back the new balance: $2000.  The second task then ends, and control returns to the first task.  The first task wants to withdraw $200, and knows nothing about the second task.  Therefore, it takes the money that it just read was in the account, $500, subtracts $200 from it and writes your new balance to the account: $300.  You just "lost" $1500 in this process.  Ouch!

Now, consider what would happen if you were using semaphores.  The first task would try to grab the semaphore.  Since no one else is accessing your account, it would get the semaphore.  It would then read the balance as $500.  The first task is then suspended and the second task starts.  Instead of reading the balance first, the second task goes to grab the semaphore.  Since the first task has the semaphore, it isn't available and the second task must wait for it.  Hence, the second task is suspended, and so it must wait.  The first task then resumes, withdraws $200 from the account, and writes the new $300 balance back.  It then returns the semaphore.  The O/S, or whatever task controller is controlling the semaphore, notices that the second task is waiting for it.  It then reactivates the second task, giving it the semaphore.  This task now reads the balance in the account as $300, adds your $1500 paycheck, and writes the new $1800 balance back.  The second tasks releases the semaphore and our example is complete--no money was lost when semaphores were used.

While this may sound like a fictitious example, there are many examples within a computer that fit within this model.  Imagine what would happen if more than one process was trying to read from a FIFO--such as from a serial port.  A semaphore could be used to make sure that only one task is adjusting the FIFO pointers at a time.  As another example, you might use semaphores to ensure only one print job goes to the printer at a time, more generally you can ensure that only one hardware controller accesses the hardware at any one time.  Jurgen's book even describes how you can use semaphores to synchronize two processes--so that they both start or stop at the same time, or so that one waits until the first has done ... whatever.

In other words, semaphores are *very* valuable for coordinating two processes.

They are not the only means of coordinating two tasks/CPU's, but they are one valuable means for doing so.  Usually a CPU will support some special instructions using the bus, such as an atomic increment or decrement operation.  Indeed, the AXI bus specification reserves a whole chapter to explaining how such CPU primitives can be implemented, but I digress.

Hope this helps,

Dan

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

Hi, I am trying run a deep CNN programm in Zynq-7000 SoC. I want to use fpga for training and ARM processor for prediction. How can i do that?

Edited by saj

Share this post


Link to post
Share on other sites
  • 0
On 3/25/2019 at 11:58 AM, saj said:

Hi, I am trying run a deep CNN programm in Zynq-7000 SoC. I want to use fpga for training and ARM processor for prediction. How can i do that?

Which board are you using? Can you provide more details about the neural network and your design?

Share this post


Link to post
Share on other sites
  • 0
On 3/25/2019 at 11:58 AM, saj said:

Hi, I am trying run a deep CNN programm in Zynq-7000 SoC. I want to use fpga for training and ARM processor for prediction. How can i do that? 

As far as I know the NN training phase takes long time and needs many resources. For this reason it is not recommended to train NN on FPGAs. On the other hand, FPGA is strong in inference. I advise you to use GPU and a learning framework, like Caffe, for the training phase.

Fortunately, Xilinx released recently a new development kit for NN named Deep Neural Network Development Kit (DNNDK). Here you have the user guide and the DNNDK extension for SDSoC. Have a look on the Xilinx documentation and forum posts to get familiar with all concepts. Let us know if you have any questions.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now