Clocking Issues With pmodOLEDrgb

[wanderso]

I've been trying to run a OLEDRGB display on my Arty, using the sample pMod learnable and Vivado on my new machine. It had worked perfectly on my old machine, but unfortunately on the new machine I'm getting some issues with the clocking - it's running roughly 1000 times slower (I checked) than it actually should be. I get some critical warnings when I try to make a bitstream:

[Common 17-55] 'get_property' expects at least one object. ["/home/wanderso/Tools/VivadoProjects/ARTY_Display_Attempt_2/ARTY_Display_Attempt_2.srcs/sources_1/bd/system/ip/system_PmodOLEDrgb_0_0/ip/PmodOLEDrgb_axi_quad_spi_0_0/PmodOLEDrgb_axi_quad_spi_0_0_clocks.xdc":51]

That warning appears in 5 other places as well. Digging a bit deeper, I found this critical warning in the tcl process-

CRITICAL WARNING: [IP_Flow 19-4965] IP PmodOLEDrgb_axi_quad_spi_0_0 was packaged with board value 'digilentinc.com:zybo:part0:1.0'. Current project's board value is 'digilentinc.com:arty:part0:1.1'. Please update the project settings to match the packaged IP.

Putting these two things together, I *think* it indicates that the pMod IP files I have are for Zybo, and I'm supposed to have the version for Arty? But I used the most recent board files and ip/ifs from Digilent's github. Could anyone help me with this?

 

[JColvin]

Hi wanderso,

I can't personally speak towards the tcl error you're receiving; I'll ask some of our applications engineers to look into this and amend it.

As for the the code running about a 1000x slower, this is apparently (according to what another user found on this thread) a usleep() function being macro'ed to milliseconds rather than microseconds. I thought this would have been fixed by the appropriate engineers who wrote the code since that particular post isn't new, but apparently that isn't the case...I'll also make sure this gets corrected.

Thank you,
JColvin

[wanderso]

Yeah, I saw a "06/15/2016: fixed usleep delays" in the code's revision changes, but the usleeps were still assumed to be microseconds in length, not milliseconds. Probably just didn't get committed right. I tried manually changing the usleep duration in the Xilinx/Vivado SDK (actually just reskinned Eclipse), but the file system overwrote my changes when I tried to push everything to the FPGA. Is there something special I have to do to fix this myself, or should I just wait for this to get corrected?

[JColvin]

I'm hoping that one of our applications engineers will be able to chime in with a recommended fix or push a new update in a reasonable time frame since I don't personally know what would need to be done (I've only managed to set aside enough time to teach myself some basic combinatorial logic in FPGA land so far). So, either-or?

[sLowe]

Hey,

The quick fix to edit the BSP driver files is to just drag them into your project src along with your main. This will make sure that even if your BSP gets rebuilt, you will still have your changes. I've added this to our to do list and should be pushed up relatively soon.

To make these projects work in both microblaze and zynq we usually use a custom delay function. For some reason this project didn't get it.

#ifdef XPAR_MICROBLAZE_ID
	#define ITERS_PER_USEC   (XPAR_CPU_CORE_CLOCK_FREQ_HZ / 1000000)
#else
	#define ITERS_PER_USEC     (XPAR_PS7_CORTEXA9_0_CPU_CLK_FREQ_HZ / 1000000)
#endif

void delay(int micros){
	int i;

#ifdef XPAR_MICROBLAZE_ID
	for(i = 0; i < (ITERS_PER_USEC*micros); i++){
			asm("");
	}
#else
	usleep(micros);
#endif
}

Thanks,

Sam

[sLowe]

They got changed when you programmed to the FPGA? Not when you regenerated the BSP?

I don't know why that would happen. If the usleep gets called in the .c file within the BSP/libsrc/PmodOLEDrgb you should be able to make edits. They should stay as long as you don't regenerate the BSP. 

The next step I would take would be to delete your BSP/Project then go into the files yourself in vivado-library\ip\Pmods\pmodOLEDrgb_v1_0\drivers\PmodOLEDrgb_v1_0\src and make the changes and save. You will then need to go back into vivado and update your IP. Rebuild the prject, then open sdk and create a new project and BSP. The changes should now be in your new BSP and will be included when you program your FPGA.

Hope this works. I would try doing this instead of waiting for the applications team to get to this since for most of them it is Thanksgiving break. If you can branch and edit this gist with the changes, Id be happy to push it up to git for you!

https://gist.github.com/SamKLowe/21087f1238e0f24f761a08aa24f75629

-Sam