ZAP 2.3.0-- using Xilinx #include files


JPElectric

Recommended Posts

 

An inherited project has the following #includes in main.c:

 

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

 

#include "xparameters.h"

#include "xgpio.h"

#include "xio.h"

#include "xstatus.h"

#include "xuartlite.h"

#include "xtmrctr.h"

#include "xintc.h"

#include "xil_exception.h"

 

ZAP 2.3.0 barfs on the Xilinx #includes:

 

main.c:37:25: error: xparameters.h: No such file or directory

main.c:38:19: error: xgpio.h: No such file or directory

main.c:39:17: error: xio.h: No such file or directory

...

 

Hardwiring the paths complicated this, as the referenced #includes reference others: 

 

#include "/opt/Xilinx/14.7/ISE_DS/EDK/sw/XilinxProcessorIPLib/drivers/gpio_v3_01_a/src/xgpio.h"

 

results in:

 

In file included from main.c:27:

/opt/Xilinx/14.7/ISE_DS/EDK/sw/XilinxProcessorIPLib/drivers/gpio_v3_01_a/src/xgpio.h:123:23: error: xil_types.h: No such file or directory

/opt/Xilinx/14.7/ISE_DS/EDK/sw/XilinxProcessorIPLib/drivers/gpio_v3_01_a/src/xgpio.h:124:24: error: xil_assert.h: No such file or directory

/opt/Xilinx/14.7/ISE_DS/EDK/sw/XilinxProcessorIPLib/drivers/gpio_v3_01_a/src/xgpio.h:125:21: error: xstatus.h: No such file or directory

 

Even if this worked, it is not evident which of the multiple versions of the

various *.h files to reference (ppc405, microblaze, ppc440, cortexa9, ...)

 

How are the Xilinx headers to be referenced in a ZAP project?  There does not

appear to be a place to specify the many directories where these files are located.

 

Which ones should be included for the Papilio Pro?

 

Link to comment
Share on other sites

Hello,

 

The ZAP IDE is currently meant to be compatible with many of the Arduino libraries. We have not taken any steps yet to port the Xilinx C libraries from the EDK to the ZAP IDE. It should be theoretically possible, but could take a lot of work. What are you trying to accomplish? Maybe we can help.

 

Thanks,
Jack.

Link to comment
Share on other sites

The project is a machine control comprising several *.vhd and one *.c file.

The *.c file needs refactoring, bug fixes, and additional features.

The C code is tightly coupled to the hardware, i.e.; 

XUartLite_SetRecvHandler(&UartLite, RecvHandler, &UartLite);

It is not an option to implement this part of the system entirely

in VHDL.

 

Presumably the *.vhd files create a bitstream in ISE; the *.c file

is compiled and linked with avr-gcc; then these two are merged in

Papilio Loader "Write to: Disk File", which is then transferred

to the Papilio.  Correct?

 

This project came with no project files for any IDE, not even a

minimal Makefile for avr-gcc.  There is a complete bitstream that

is running the hardware on a Papilio, but there is no documentation

on the steps used to create it.

 

First the correct #include files for the Papilio/ Spartan 6 target

must be identified from among their multiple instances in the ISE 

subdirectories.  This would permit setting avr-gcc's CFLAGS I(nclude) switch

in a Makefile, as a minimal solution to create the object file so refactoring 

can proceed.

 

If this were to be entirely supported in ZAP, perhaps you can outline the 

steps involved, so any work done will parallel that effort.

Link to comment
Share on other sites

 

Presumably the *.vhd files create a bitstream in ISE; the *.c file
is compiled and linked with avr-gcc; then these two are merged in
Papilio Loader "Write to: Disk File", which is then transferred
to the Papilio.  Correct?
 

I don't think so.  This looks like a Microblaze EDK project where the hardware is developed in XPS and the software in SDK.  UartLite is a hardware module available in XPS and the software functions (like XUartLite_SetRecvHandler() ) is part of the Microblaze SDK libraries for XPS.

 

To port this over to ZAP which uses a completely different processor with completely different support modules (like uarts and timers) would be quite an undertaking.  You basically will have to recreate the equivalent of the XPS hardware from scratch in ZAP using the i/o modules available in ZAP, and then rewrite the software from scratch using the ZAP module libraries instead of the XPS module libraries.  Not a simple task.

 

It doesn't sound like it but if you have the complete SDK workspace for this project (which contains all the software as well as information about the hardware platform) then you could in theory use the free SDK to update the firmware.  However, if you need to make hardware changes then you will need the complete XPS project files and an EDK license which is not free.

 

Magnus

Link to comment
Share on other sites

It is not known how the bitstream was created; however Papilio Loader transferred it to a Papilio Pro and it is running with the UARTs and all I/O functions working correctly.  Therefore the correct processor type must have been selected.  The initial assumptions were that ZAP could use the *.vhd, *.ucf, and *.c files as input and somehow spit out a usable bitstream.   What other (more laborious) methods could be used to accomplish this, using the ISE WebPACK, Papilio utilities, and avr-gcc (et. al.)?

Link to comment
Share on other sites

>> It is not known how the bitstream was created; however Papilio Loader transferred it to a Papilio Pro and it is running with the UARTs and all I/O functions working correctly.

Sure, Papilio Loader can load any bit file created for Papilio Pro no matter how it's created.

 

>> Therefore the correct processor type must have been selected.

I'm not sure what you mean by that.  The bit file contains the whole design including the processor so there is nothing to select.  Papilio Loader knows nothing about processors, it just loads the bit file.

 

>> The initial assumptions were that ZAP could use the *.vhd, *.ucf, and *.c files as input and somehow spit out a usable bitstream.

Alvie should probably answer this but my guess is that this is not possible. The vhdl files are most likely a custom module written for XPS and only contains a fraction of the hardware platform, the rest of the system is provided by XPS, like UartLite.

 

>> What other (more laborious) methods could be used to accomplish this, using the ISE WebPACK, Papilio utilities, and avr-gcc (et. al.)?

Without having the XPS xml file that describes the hardware platform the only way to understand the hardware is to look at the c code and see what it's initializing etc. to figure out all the I/O modules and memories etc. thats needed.  You would then somehow (ZAP?) create a new hardware platform that contains what you need in one form or another (uarts, timers etc), and then modify the c code to use the new hardware platform. Without seeing the vhdl, ucf and c code it's difficult to give any more specific advice.

 

Magnus

Link to comment
Share on other sites

Absolutely.  Microblaze is a 32-bit RISC processor that runs great on Spartan 6, typically at 100 MHz or higher.  Much more powerful than an AVR or ZPUino.

 

 

Information about EDK:

http://www.xilinx.com/tools/platform.htm

 

Information about Microblaze:

http://en.wikipedia.org/wiki/MicroBlaze

http://www.xilinx.com/tools/microblaze.htm

 

Example of a module available in XPS (UartLite):

http://www.xilinx.com/support/documentation/ip_documentation/axi_uartlite/v1_02_a/axi_uartlite_ds741.pdf

 

Tutorial of how to design a Microblaze embedded system using a Spartan 6 LX9:

http://www.eeworld.com.cn/uploadfile/Xilinx/uploadfile/201107/20110712024756897.pdf

 

Magnus

Link to comment
Share on other sites

Thank you for helping out with this information Magnus. 

 

ZAP IDE is not compatible with the EDK files, your best path to support the project you inherited is to recreate it with the EDK or find the original EDK definition files. Whoever made the project used the EDK instead of ZAP IDE, as evidenced by the usage of UARTLite, and they targeted the Papilio board using a ucf file and possibly a bsb file. Your best bet is to get a hold of those files that they created.

 

Jack.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.