UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Participant svenssonjoel
Participant
5,354 Views
Registered: ‎03-17-2016

Correct protocol for starting (and restarting, over and over again) a OpenCL workgroup in the Zynq PL

Hello,

 

Say that I have the hardware generated for an openCL workgroup in my PL.

  - It has a Programming-registers (control, group_id_x and so on registers) mapped to some memory address (0x43c00000).

  - it has a axi mem interface, through which it can fetch and store data.

  - programming registers are hooked to GP0 AXI master

  - memory "axi" interface is hooked to GP0 AXI slave

 

I have been very succesfully launching workgroups like this by doing the following:

  - write appropriate values into the "programming-registers" but saving "control" for last.

  - after that I set bit zero of control (for START)

 

As I understand it now I should be able to poll control until the done bit is set (bit 1). 

But on occasions (and with workgroups that perform very heavy memory io) things get stuck and

reading the control register shows a value of 1 (in other words, the start bit is set). I did not really think

that should ever happen. 

 

I am thinking I am missing some parts of this "protocol", maybe after telling the workgroup to start there

must be a delay before poking the control register again (of some ns) ? or is there something else ?

 

If any of you experienced hardware guys immediately know what is up here, please fill me in.

 

Thank you very much and best regards

 

4 Replies
Teacher muzaffer
Teacher
5,351 Views
Registered: ‎03-31-2012

Re: Correct protocol for starting (and restarting, over and over again) a OpenCL workgroup in the Zynq PL

I am not sure if things are different between c/c++ & opencl designs but my understanding is that ap_start bit is self clearing ie the user sets it and it stays set till done bit is set when ap_start get cleared automatically.
So what you observe seems to be expected.
You can also connect an interrupt to done so that you don't have to poll the done bit.
- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
Participant svenssonjoel
Participant
5,347 Views
Registered: ‎03-17-2016

Re: Correct protocol for starting (and restarting, over and over again) a OpenCL workgroup in the Zynq PL

Thanks for that feedback, muzaffer. 

It does look like my understanding was not too far off then.  The real problem in my question

is however the "getting stuck" part.

 

So say i do the following

 

loop:

if (done or idle) {

   start_the_hardware

}

goto loop

 

The above is the scenario that causes the "hardware" to (as i see it) freeze and the control register remains at 1 (forever!)

 

But I have experimented with small tweaks

 

loop:

usleep(10);

if (done or idle) {

   start_the_hardware

}

goto loop

 

And the stalling/freezing behaviour goes away. This is why I wondered if there might be a recommended time

interval between "poking" the control register after isuing a start.

 

usleep(10) is not a huge amount of time in relation to the PL (should be just one cycle of the hardware unit).

 

Thanks again and best regards

 

0 Kudos
Participant svenssonjoel
Participant
5,334 Views
Registered: ‎03-17-2016

Re: Correct protocol for starting (and restarting, over and over again) a OpenCL workgroup in the Zynq PL

Sorry was a bit off there, usleep(10) is a large amount of time in relation to the PL ;) 

0 Kudos
Participant svenssonjoel
Participant
5,251 Views
Registered: ‎03-17-2016

Re: Correct protocol for starting (and restarting, over and over again) a OpenCL workgroup in the Zynq PL

I gave kudos on your reply, muzaffer. Moving over to using interrupts does sounds like a very good idea. 

I still want to understand the details of what is going wrong with my current setup though. 

 

0 Kudos