cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
guinnesstrinker
Adventurer
Adventurer
2,618 Views
Registered: ‎08-23-2012

SDK 2017.4: wrong names for base addr in xparameters.h

When exporting a Zynq-design with custom ip-cores to SDK the resulting .hdf looks like expected.

My design has an ip-core with more than one AXI-interfaces (S00_AXI, S01_AXI, S02_AXI).

In hw_platform system.hdf all baseaddresses etc. are correctly.

 

When generating a BSP in xparameters.h the names for the addresses of my ip-core do not include the AXI-interface like it was in earlier times (2015.4 for example).

 

As a result there is only one address available in xparameters.h

 

Details in 2015.4:

/* Definitions for peripheral FSBUS_0 */
#define XPAR_FSBUS_0_S00_AXI_BASEADDR 0x43C10000
#define XPAR_FSBUS_0_S00_AXI_HIGHADDR 0x43C1FFFF
#define XPAR_FSBUS_0_S01_AXI_BASEADDR 0x8AA20000
#define XPAR_FSBUS_0_S01_AXI_HIGHADDR 0x8AA2FFFF
#define XPAR_FSBUS_0_S02_AXI_BASEADDR 0x8AA30000
#define XPAR_FSBUS_0_S02_AXI_HIGHADDR 0x8AA3FFFF

 

Details in 2017.4:

/* Definitions for peripheral FSBUS_0 */
#define XPAR_FSBUS_0_0 0x8AA20000
#define XPAR_FSBUS_0_0 0x8AA20000

 

 

What is going wrong?

How can I fix it?

Is it a bug in SDK 2017.4?

 

 

0 Kudos
9 Replies
guinnesstrinker
Adventurer
Adventurer
2,600 Views
Registered: ‎08-23-2012

Same problem discussed in (Vivado 2017.2):

 

https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Missing-Interfaces-in-xparameters-h/m-p/810096

 

Changing the name in properties (Message 4) is no solution. They are already different.

 

So I think it's a bug in Vivado/SDK 2017.x.

( or a hidden option that has to be activated ).

 

0 Kudos
gmarinkovic
Explorer
Explorer
2,583 Views
Registered: ‎01-09-2012

@guinnesstrinker

 

Can you try following:

1.) In your BSP set the drivers to generic

2.) Clean software project, hence the BSP is regenerated.

 

Do you see then the base addresses of your components?

 

Cheers

Goran

0 Kudos
guinnesstrinker
Adventurer
Adventurer
2,579 Views
Registered: ‎08-23-2012

All drivers of my own IPs are generic by default, because there are none (driver).

 

 

 

screenshot_2018-03-07_162026.png
screenshot_2018-03-07_162047.png
screenshot_2018-03-07_162059.png
0 Kudos
gmarinkovic
Explorer
Explorer
2,566 Views
Registered: ‎01-09-2012

@guinnesstrinker

 

What a tricky problem... so your three components did pop up in the old Vivado 2015 but not in 2017. Let me guess you see the 3 components in the address view in Vivado and pressing F6 tells everything is ok? Then you compile and export the hardware to SDK sucessfully? Then you regenerated the BSP and you are pointing to the correct hardware? You have checked that in your hardware folder you see the new files an no old files?

Most of the times when Vivado tries to test my mental strength I delete all generated files manually and then regenerate the whole blob of data again keeping only the very basic set of files. In all cases I was fighting with the tool this was the only way to proceed with my work.

 

Cheers

Goran

0 Kudos
guinnesstrinker
Adventurer
Adventurer
2,551 Views
Registered: ‎08-23-2012

I started a new (empty) project/workspace in SDK. So there is no update-problem.

 

gmarinkovic
Explorer
Explorer
2,547 Views
Registered: ‎01-09-2012

@guinnesstrinker

 

...some of the Vivado issues are best solved with a Guinness ;-)

 

Cheers

Goran

0 Kudos
johnmcd
Xilinx Employee
Xilinx Employee
2,527 Views
Registered: ‎02-01-2008

I expect that the separate address ranges for your ports were created using a device driver for your custom IP. Search your old design for a .mdd file. It's possible that your old sdk project pointed to a repository that contained your <customIP>/data/<customIP>.mdd. And within the data directory, there is probably also a <customIP>.tcl file which is responsible for assigning/defining what is added to the xparameters.h

 

If you choose the generic driver, then its .tcl in the sdk install directory (I.E. c:\xilinx\sdk\2017.4\data\embeddedsw\XilinxProcessorIPLib\drivers\generic_v2_0\data\generic.tcl) only assigns a single default base and high address.

 

Feel free to browse the .tcl for other drivers to get an idea of how cores with multiple ports and maybe interrupts, insert information into the xparameters.h.

0 Kudos
stephenm
Moderator
Moderator
2,455 Views
Registered: ‎09-12-2007

Is this a custom IP?
If so, then you can just update the driver (data-> driver_name.tcl) to include all the address spaces.

You can use the AR below for assistance here:
https://www.xilinx.com/support/answers/64980.html
0 Kudos
guinnesstrinker
Adventurer
Adventurer
2,364 Views
Registered: ‎08-23-2012

Sorry for the delay. I was out of office for some days.

 

When I created these ipcores years ago the wizzard also build a so called driver.

To stay at my "fsbus" example the content of

 

X:\ip_repo\fsbus_1.0\drivers\fsbus_v1_0\data\fsbus.tcl

 

was

 

proc generate {drv_handle} {
    xdefine_include_file $drv_handle "xparameters.h" "fsbus" "NUM_INSTANCES" "DEVICE_ID"  "C_S00_AXI_BASEADDR" "C_S00_AXI_HIGHADDR" "C_S01_AXI_BASEADDR" "C_S01_AXI_HIGHADDR" "C_S02_AXI_BASEADDR" "C_S02_AXI_HIGHADDR"
}

 

I changed it to the newer TCL syntax ("::hsi::utils::define_include_file ..").

 

Then I also added a local repository in SDK.

 

This was NEVER needed before. I always got the addresses into BSP with .hdf only!

 

As a result I get the missing names in xparameters.h, BUT wrong numbers:

 

/* Definitions for driver FSBUS */
#define XPAR_FSBUS_NUM_INSTANCES 1

/* Definitions for peripheral FSBUS_0 */
#define XPAR_FSBUS_0_DEVICE_ID 0
#define XPAR_FSBUS_0_S00_AXI_BASEADDR 0xFFFFFFFF
#define XPAR_FSBUS_0_S00_AXI_HIGHADDR 0x00000000
#define XPAR_FSBUS_0_S01_AXI_BASEADDR 0xFFFFFFFF
#define XPAR_FSBUS_0_S01_AXI_HIGHADDR 0x00000000
#define XPAR_FSBUS_0_S02_AXI_BASEADDR 0xFFFFFFFF
#define XPAR_FSBUS_0_S02_AXI_HIGHADDR 0x00000000

 

What's wrong?

 

 

Remember: As you can see in screenshots above the correct addresses had always been provided through .hdf (system.hdf).

 

At our company there are different people working at HW- and SW-Design.

So it will cause much more work to transfer not only the .hdf, but also the corresponding ip_repo tree.

 

 

0 Kudos