How to create low level Software functions to handle a custom IP

Hi !

In this post we will create basic low level software to handle our custom IP.

There are several goals here :

- Will we see how to test this low level software using HDL simulation of a MicroBlaze subsystem. This is a great tool to start building the software developement task without any board !

- This low level software can then be packaged in different ways to make a standalone driver, a Linux device driver, or a test application. They will all be based on simple routines to achieve simple tasks with the custom IP.

This post will be based on the MicroBlaze subsystem defined in the following post:

2.3 - How to create a Microblaze design to simulate low level Software Functions


As this post is quite long, here are the main sections of this post for a quick jump :

• Step 1 : Creating the VIVADO Project
• Step 2 : Creating the Microblaze Subsystem
• Step 3 : Writing the test application
• Step 4 : Simulating the software running on the hardware

Step 1 : Exporting the hardware platform for the software project

There are here a few things to understand.

Good to know :

The software developement will be done in the provided tool, the Xilinx SDK environment.

As the software uses the hardware, its has to know what is the provided hardware for the current project. This is really easy, the VIVADO tool will export the HDF file (Hardware Definition File) which is an encrypted container file that embedds everything needed !

Each time you make changes to your VIVADO project, you have to regenerate the HDF file, which will be automatically detected by SDK to recompile the whole software environment.

Stage 1

First thing to do is to export the VIVADO hardware project.

But as our source files are only based on a Block Design file we have to convert it to an HDL file.

Easy !

In the Block Design window select the Sources tab.

Then right click on the BD file and click Create HDL wrapper.

Then a pop up will ask you if you want to handle the file or if you want VIVADO to do it for you.

As this is an exemple project, we will let VIVADO do it for us.

So click Next.

Stage 2

So, the wrapper has been generated, added to the source files and the source section has been updated.

To see if everything is fine with our Design let's generate the output from the Block Design content.

Select the Block Design source file and right click to Generate Output Products.

To check the validity of the Block Design content you could also click the Validate Design button or press F6.

Then the generate output function will provide the Configuration pop up.

Just use the global option and click Generate.

You can follow the generation steps in the Tcl Console Window.

Terminate the generation step by clicking Ok on the last pop up.

Stage 3

Now let's generate the hdf file.

Once again it's easy !

Go to File, then Export and Export Hardware.

Once again the tool asks you if you want to handle the repository of the hdf file or if you want him to handle it for you. Let it do the job !

Select Ok.

It's done !

Step 2 : Creating the software project

Stage 1

Now let's create the SDK Software project.

Go to File, then Launch SDK.

And again the tool asks you if you want to handle the repository of the software project or if you want him to handle it for you. Let it do the job !

Select Ok.

Depending on your system, it will take some time to open the project in SDK.

Stage 2

Now we are in the SDK project automatically created for us.

You have to know that for a basic standalone SDK project you must have the following items :

1. The hardware platform (Created By VIVADO)
2. A BSP (Created by SDK)
3. An Application (Created by SDK)

For now the SDK tool created for us the hardware platform from the exported hdf file.

So if you look in the project explorer, the first section is the Hardware Platform, where you find the system.hdf file.

In the right window there is an overview of the hdf file with various information.

The first important information is the mapping of the system, where you can find our IP mapping in the system.

The second important information is the list of the IPs in the system, and hopefully our IP is in the list !!!

Another important point that you migth have noticed, is that our custom IP has its associated software driver automatically included in the drivers section !!!

This is very nice because when your driver is finalized, you don't have to care about providing it to the software project, it is automatically included whn you use the IP.

For now this is the template generated by the Custom IP generation wizzard and it contains nothing very interesting, we'll come back to it in the following posts.

Stage 3

We still have to generate the BSP and the application.

You can either create both manually, or BSP can be automatically created for us on application creation ! This is what we're going to do.

So, in the File menu, select New, then select Application Project.

Then the Application Project configuration window pops up.

Provide the name of our project.

Verify that Create New is selected for the BSP auto creation.

Click on Next.

Here you can use a template for several application use cases.

We'll use the Empty Application one.

Click Finish.

So the tool populated the BSP (2) and the application (3) sections.

The tool also opened the BSP overview in the system.mss file. We can check that our IP's driver is available in the BSP.

In the application section we can check that there is no source file excepted the auto generated linker script file lscript.ld.

Ok, the tool helped us a lot in generating all the resources needed for the SDK software project.

Now we have to write some C !

Step 3 : Writing the test application

Stage 1

First thing to do, create our source file. Here we only create a basic main.c file.

So on the src repository of the application section, right click for New, then Source File.

So give it the main.c name and click Finish.

Now the file appears in the src repository and is opened by the tool, ready for edition.

Stage 2

Let's write the C code.

Good to know :

For software developement there is a very important practice to understand and apply.

The low level functions we are going to write are intended to be used in drivers or application, for standalone or Linux. To have them portable among all these contexts, writing and reading in IPs shall be done using pointers.

As these low level functions will access hardware resources inside the IPs, software has to know the hardware properties (address, configuration parameters......). For standalone application, everything is available in the xparameters.h file located in the led_test_bsp > microblaze_0 > include.

First section : the includes files

Here only one thing will interest us, the hardware parameters. So let's include the xparameters file.

#include "xparameters.h"

Second section : the variable declaration

The first variable needed is the pointer to the IP's hardware registers, let's call it ptr_ip.

The second variable needed, is a counter for temporization creation, let's call it tempo.

int main()
{

 unsigned int *ptr_ip;   // To access IP's registers
 unsigned int tempo;     // To wait some time between actions

Third section : initialize the pointer

To access the physical registers of the IP, first initialize the pointer to the IP's registers base address.

The base address (XPAR_LED_TEST_IP_0_S00_AXI_IN_BASEADDR) is provided in the xparameters.h file.

    // Initialize pointer to IP's base address
    // This provided by the xparameters.h file
    ptr_ip = (unsigned int *)XPAR_LED_TEST_IP_0_S00_AXI_IN_BASEADDR;

Fourth section : sequence definition

For example we will define the following test sequence :

- Generate a temporization
- Set the mode ON, the LED should be set

 // Tempo
 for(tempo=0; tempo<100; tempo++);

 // Set mode ON
 // Activate bit 0 of register at offset 0x00
 *(ptr_ip + 0x00) = 0x00000001;
 // Apply configuration by generating rising edge on bit 24 at offset Ox0C
 *(ptr_ip + 0x03) = 0x01000000;
 *(ptr_ip + 0x03) = 0x00000000;

- Generate a temporization
- Set the mode OFF, the LED should be unset

 // Tempo
 for(tempo=0; tempo<100; tempo++);

 // Set mode OFF
 // De activate bit 0 of register at offset 0x00
 *(ptr_ip + 0x00) = 0x00000000;
 // Activate bit 8 of register at offset 0x04
 *(ptr_ip + 0x01) = 0x00000100;
 // Apply configuration by generating rising edge on bit 24 at offset Ox0C
 *(ptr_ip + 0x03) = 0x01000000;
 *(ptr_ip + 0x03) = 0x00000000;

- Generate a temporization
- Set the mode BLINK, the LED should blink using the value set in the IP's GUI in the Block Design editor.

 // Tempo
 for(tempo=0; tempo<100; tempo++);

 // Set mode BLINK
 // De activate bit 8 of register at offset 0x04
 *(ptr_ip + 0x01) = 0x00000000;
 // Activate bit 16 of register at offset 0x08
 *(ptr_ip + 0x02) = 0x00010000;
 // Apply configuration by generating rising edge on bit 24 at offset Ox0C
 *(ptr_ip + 0x03) = 0x01000000;
 *(ptr_ip + 0x03) = 0x00000000;

Stage 3

Once the C source code is written it has to be compiled.

SDK is configured to launch automatically source compilation on source file save.

Otherwise you can use Project > Built all, or Ctrl + B

Building results are available in the Console.

There was no error and the output led_test.elf file is generated.

Step 4 : Simulating the software running on the hardware

Stage 1

The system RTL behavioral simulation is launched from VIVADO, so go back to the VIVADO tool.

The first thing to do is to tell the VIVADO tool to initialize the MicroBlaze's BRAM instruction memory with the generated led_test.elf file.

Go for Tools then Associate ELF Files...

This will open the ELF File Association window.

This is where you will specify which elf file will initialize the MicroBlaze's BRAM instruction memory for implementation and for simulation.

elf files can be different for implementation and for simulation.

The default file is the one called mb_bootloop_le.elf, it is provided by Xilinx and mostly, it will put the Microblaze in a inactive infinite loop after its initialization.

So, click on the file section of the simulation.

Then provide the path to the led_test.elf file we've just generated.

Click Ok, then Ok.

Stage 2

Now that software has been added to the simulation, let's launch the simulation.

This is done in VIVADO, on the left side, in the SIMULATION section.

Click on Run Simulation.

This will pop up the list of available simulation runs.

Click on the Run Behavioral Simulation.

This will launch the internal simulator of VIVADO called XSIM.

The main advantage of this simulator is that it handles everything for you !

Everything that has to be generated or compiled is done automatically by the tool !!

If you want to use Modelsim, no problem, VIVADO will generate for you all the needed scripts.

For my personal projects, I don't use anymore Modelsim, because XSIM is really enougth for my needs and it's FREE !!!

Stage 3

So after some time (depending on the content of your design and the efficiency of your computer) the simulator will open its window in the VIVADO layout.


Add the signals you want to see, set the simulation duration time and then Run the simulation !

And here you are :

You can see that :


- The clock is running,

- The reset is activated and released,

- The sequence of the 3 modes is there with the temporizations.


And so that's it !


The test software application can access the IP's registers and can be simulated to achieve the expected behavior.

Post Conclusion

Now we have :

- Created a VIVADO Project,
- Created the MicroBlaze Subsystem,
- Set the memory mapping of the MicroBlaze Subsystem,
- Written low level software to access the IP's registers,
- Simulated the software to achieve the expected behavior of the software.

The written software is very low level, now it has to be written in a more structured way to be used in drivers !

This will be done in next posts.

How to create a Microblaze design to simulate low level Software Functions

Hi !

In this post we will create a Microblaze subsystem connected to our Custom IP in order to write and test in simulation the low level software functions that will be used in the future driver of our custom IP.

As this post is quite long, here are the main sections of this post for a quick jump :

• Step 1 : Creating the VIVADO Project
• Step 2 : Creating the Microblaze Subsystem
• Step 3 : Set the memory mapping of Microblaze Subsystem

Good to know :

A major thing here to understand is that software access to our custom IPs can be simulated !

Ok and how is that possible ?

It can be easilly done by using a Microblaze. A Microblaze is a HDL softcore processor so it can be simulated. As the processor can run its software from its local BRAM, which are HDL IP's, the only thing to do is to initialize the BRAM's content with the .elf file generated by the SDK tool.

This is only associated with Microblaze core and HDL IPs. For ARM cores, simulation possibilities are limited and in my point of view much more complex to use.

Step 1 : Creating the VIVADO Project

Stage 1

First thing to do is to create a VIVADO projet for your device.

Launch VIVADO.

Click the Create Project from the Quick Start links

This will open the New Project pop up window, click Next.

Stage 2

Then, provide the name of your project, here I used test_proj.

Provide the destination repository.

Select the Create project subdirectory if you want the tool to put your project in a sub directory with the name of your project. Otherwise it will be in the destination repository. This is usefull if you need to store other things in the destination repository, things will be sorted.

Finish with Next.

Stage 3

The next window of the wizzard is the project type, leave to RTL Project, click Next.

Stage 4

The next window of the wizzard is the add source, here nothing to add, so select Next.

Stage 5

The next window of the wizzard is the add constraint, as we will only do a simulation and not an implementation we have nothing to add, so select Next.

Stage 6

The next window of the wizzard is the part selection.

As we will only do a simulation and not an implementation you can select any device reference, here I will use the MiniZed board. Then select Next.

Stage 7

And last, the Project Summary, select Finish.

Step 2 : Creating the Microblaze Subsystem

Basically this is assembling IP's in a Block Design !

Stage 1

Let's create a Block Design file.

On the left side select IP INTEGRATOR then Create Block design.

Provide a name if you want, leave everything else to default values, which will let VIVADO handle the Block Design in the VIVADO's project structure.

Click Ok.

Stage 2

First thing to do to use our custom IP is to provide the path to the VIVADO project.

In PROJECT MANAGER launch the settings command.

Select IP, then Repository section.

Click on the add cross to select the IP's repository.

The tool will provide the list of identified IPs and Interfaces.

Click OK and OK.

Ok, VIVADO knows our IP.

Stage 3

Now, let's add the IP to our design.

In the Block Design diagram edition window on the right, click on the add symbol to add our IP.

This will open the IP search pop up.

Filter with the led word, our IP should show up !

Select the IP in the list and press enter to add the IP to the BD.

There it is !!

Stage 4

Now, let's add the MicroBlaze subsystem to our design.

Again, select the add symbol and search the word Microblaze.

There will be 3 matches, select the MicroBlaze one, press enter.

The Microblaze IP is now in the design, BUT, it has to be configured.

Instead of adding all the associated IPs (reset, BRAM, BRAM Controller, clocking, .....) the tool provides a magic function, the Run Block Automation.

Click on Run Block Automation to launch the associated wizzard.

In this window you'll find all nevessary parameters to configure the entire MicroBlaze subsystem.

Set Local Memory to 64KB, in order to have enougth memory for software developement.

Set Debug Module to none because we won't do any debug.

Set Clock Connexion to External Port, no need for a clock buffer for simulation.

Finish with Ok.

Stage 5

The tool will populate the Block Design with the elements of the MicroBlaze subsystem.

As the IPs still have unconnected resources the tool will provide you with another proposition of Connection Automation !!

If you launch the Automation wizzard, you'll see that it will try to connect the AXI interface of our IP and the MMCM reset input.

For the AXI interface leave everything as proposed.

For the Reset, click on ext_reset_in to set its parameters. Use an ACTIVE_HIGH configuration and select Ok to finish.

Here is the generated result.

To finalize the Block Design we have to add the LED output.

Select the led_out pin, then CTRL+T, which adds an external connexion.

To get a clean view of the final design click the Regenerate Layout button.

Step 3 : Set the memory mapping of Microblaze Subsystem

The Block Design provides automatically the memory mapping !

Stage 1

Just select the Address Editor tab in the Block Design.

So you can see :

- Our IP led_test_ip is mapped througth the S00_AXI_IN interface.
- The tool provided a range of 64K bytes from the base address x44A0_0000.
- You can also identify the memory mapping for the MicroBlaze's Instruction and data segments.

You can modify the base address and the size allocated to our IP !


This is it !!

The hardware for our MicroBlaze system is ready.

Post Conclusion

Now we have :

- Created a VIVADO Project
- Created the MicroBlaze Subsystem
- Set the memory mapping of the MicroBlaze Subsystem

How to create an AXI4 Custom IP from scratch

Hi !

In this post we will create a custom IP with the following requirements :

- The IP will be placed in a new custom IP library
- The IP will be generated from scratch using the Vivado's wizzard
- The IP will have a slave AXI lite interface
- The IP has 4 internal registers accessible (read / write) by the processor
- The IP drives a LED with the following commands:

- The LED is set ON
- The LED is set OFF
- The LED is set blinking

- The blinking period is set using a generic parameter accessible from the Block Design GUI

As this post is quite long, here are the main sections of this post for a quick jump :

• Step 1 : Create the IP manager folder (Our library)
• Step 2 : Create our custom IP using the wizzard
• Step 3 : Edit the generated IP source files
• Step 4 : Finalize our IP in the IP editor

Good to know :

Creating custom IPs is a sub process of the Vivado tool. Vivado will provide everything to handle those IPs, even thow you can always do things manually when you know what you're doing !

The first thing to know is that Vivado provides a dedicated task to handle IP: the IP manager. This will create a dedicated Vivado project from where you can manipulate the IP library, in which your custom IPs / Interfaces can be added, removed, modified.

Then, when IPs are created, you can modify them in the IP manager or directly edit them when you use them in the block design editor, which is pretty convenient !

Finally, a custom IP is fully configurable and it is possible to easilly create the IP you've been looking for !

Step 1 : Create the IP manager folder (Our library)

Stage 1

Ok, first let's create a new project for the IP manager where we will store our library.

Launch Vivado and in the start up Tasks menu select Manage IP.

You can then either open an existing IP Manager project or create a new one.

Select New IP Location.

Then click next on the pop up screen that gives some explanations.

Stage 2

The next screen of the wizzard will let you configure the IP manager project.

First you have to select the device for which you want to create the IP.

Either you know the exact reference of you device (if you're working on a custom board for example) and you will choose the part reference in the Parts tab. Or either you are working with a dev board and you can use the pre defined settings for your board in the Boards tab.

First selelect the Boards tab.

Then in our case we select the Minized configuration.

And finally click Ok.

So back to the IP Manager settings screen.

You can select the HDL language you want, the HDL simulator you will use and the simulator's language.

In our case we will use the proposed defaults (VHDL, Vivado Simulator, Mixed).

Last thing, you have to select the folder for your library.

This folder will store the IP Manager project folder, our custom IPs folder and our custom interface folder.

I decide to call this folder my_test_ip_lib.

Finish with Select.

Ok, everything is set up, just click Finish.

Stage 3

Ok, the IP manager project is created and it opens.

You can see on the right side of the window the IP catalog proposed by Vivado, classified by categories.

IPs are stored in the Cores tab, but there is also the Interfaces tab where you can create your signals Interface.

This mandatory to simplify the graphical edition of Block Designs using IP boxes that contain many signals on their entity.

Step 2 : Create our custom IP using the wizzard

Stage 1

To create our custom IP go to the Tools menu, then select Create and Package New IP.

Stage 2

The Create and Package New IP Wizzard is launched.

Read the provided explanations.

Click Next.

In our case we want to create an AXI4 IP from scratch.

So select the Create a new AXI4 Peripheral section.

Click Next.

Stage 3

In this screen we will configure our IP.

First provide the name of the IP.

Version starts automatically at 1.0, leave this.

The display name is automatically built by the wizzard, leave it this way.

Description, you can provide what you want !

And most important, the location where the IP's folder will be stored.
Provide the path to the IP library's folder we've created in the previous steps : my_test_ip_lib.

Click Next.

This screen is very important !

This is where you will add all the main resources of your IP.

But remember, this wizzard will generate an example template, you can modify everything manually afterward !

By default we get an AXI4 Interface as requested. So we need to configure this interface :

- The interface's name. The S00_AXI is Xilinx's naming so keep it. S is for Slave and 00 for the interface index.
I always add the direction, here the interface is an input of the IP.
- The AXI4 type (Stream, Lite or Memory Map). Our IP will be controlled by a processor so a Lite interface is fine.
- The interface mode is slave. The processor is the master, it generates read/write cycles to the IP.
- The Data width of the busses, here 32 bits.
- The wizzard will generate a template with 4 registers.

Then click Next.

The next screen is the IP creation summary.

Review the information.

Select the action Add IP to the repository.

And click Finish.

Stage 4

And there it is !!!

Our IP appears in the IP catalog.

It shows that it is not in the Viado's Repository but in the User Repository.

As our IP has an AXI interface it is sorted in the AXI Peripherals section.

Stage 5

If we take a look inside the Library we've created.

Vivado created a default repository, but we will keep ours ! (Just to let you see that you can handle IPs as you want !!)

So just keep :

- managed_ip_project : which is the IP manager project's folder
- led_test_ip_1.0 : which is our custom IP's folder

Stage 6

Let's take a closer look to our IP's folder's content.

my_test_ip_lib  : Library's folder

    led_test_ip_1.0 : Custom IP structure folder

        bd : Folder containing the GUI definition in the Block Design editor

        drivers : Software drivers' folder

            led_test_ip_v1_0 : The driver auto generated by the wizzard for our IP

        example_designs : Design examples auto generated by the wizzard for our IP

        hdl : IP's sources folder

        xgui : tcl procedures for IP customization from GUI modifications

        component.xml : IP's definition file

Step 3 : Edit the generated IP source files

Stage 1

Let's take a look to the generated source files of our IP.

led_test_ip_v1_0.vhd : This is the top level of the IP. It instanciates the led_test_ip_v1_0_S00_AXI_IN.vhd module.

led_test_ip_v1_0_S00_AXI_IN.vhd : This is a template for an AXI4 Lite Slave interface.

It could be very interesting for you to have a look at this file to see how Xilinx implemented it !

Stage 2

Let's analyze the IP's top level file (led_test_ip_v1_0.vhd)

Here we have the entity. Basically, the wizzard provided the AXI4 Lite slave interface elements.

I added the G_BLINK_PERIOD generic parameter that will let us control statically from the BD's GUI the blinking period.

I also added to led_out output that will drive the LED on the board.

Some Constants and Signals declarations.

Then the wizzard made the AXI4 Lite interface module's instanciation.

I added the led_mode control register that will let us drive the LED behavior and which is generated in the AXI4 Lite module.

Last section, I added custom code.

First, a free running counter that is controlled by the G_BLINK_PERIOD generic parameter.

Second, the output stage that generates the LED behavior depending on the led_mode control register.

Stage 3

Let's analyze the IP's AXI4 Lite interface (led_test_ip_v1_0_S00_AXI_IN.vhd)

As this file is auto generated and quite long, I will let you read the file if you want an example of how generate this kind of interface.

I will just show you my modification of this file to generate the led_mode register.

Step 4 : Finalize our IP in the IP editor

Stage 1

If I open the IP Manager tool on my library's repository I can see my IP in the IP Catalog, in the User Repository section and in the AXI Peripheral category.

Then, select the IP, right click on it and launch Edit in the IP Packager tool.

Check that the editing project is located in the IP manager location, click Ok.

If the project already exists because you made previous editions, click click Ok to overwrite.

There you are, your IP is opened in the IP Packager tool !

Let's see how to finalize the IP's edition process.

Stage 2

Identification Section

In this section fields have been automatically filled.

The tool is happy, Identification section has a green tag.

You can update fields if you want, I keep them as they are.

Stage 3

Compatibility Section

This is where you specifiy the Xilinx devices familly that are compatible with your IP.

As we've designed the IP in a Vivado project set for our Minized board, the familly is the Minized's device familly, the Zynq.

You can add famillies using the Add cross, and you can set the Life cycle upon the tests you've made for your IP on each Device familly.

Everything is fine for the tool, we've got the green tag !

Stage 4

File Groups Section

This section lists all the source files that are needed to use the IP in different situations.

- The VHDL Synthesis section lists the source needed for implementation
- The VHDL Simulation section lists the source needed for RTL simulation
- The Software Driver section lists all the driver's template files
- The UI Layout section is a Tcl file to control GUI layout and customization of the IP
- The Block Diagram section list the tcl control file for IP GUI use in the Block Design editor.

For now we will leave it as it is, again we've got the green tag for this section !

You could add others elements to be packaged with the IP by using the Add cross.

Stage 5

Customization Parameters Section

This section is detected as modified because I modified the generated VHDL files !

The edit tag is shown for the section and the Merge changes from Customization Parameters Wizard action warning has pop up.

This is because I added the G_BLINK_PERIOD generic parameter in the source of the IP's top level.

To update this section, just click on the Merge changes from Customization Parameters Wizard hyperlink to launch the synchronization.

This action updates the entire IP in the IP packager tool, all the edit tags sections are updated !

In this section our G_BLINK_PERIOD generic parameter is detected, but it is for now identified as Hidden. This means it won't appear in the IP's GUI.

Just give it a check by viewing the Customization GUI. The G_BLINK_PERIOD generic parameter is still identified as hidden and does not appear in the preview sections.

So let's modify how our IP will look like in the GUI !

First of all, go back to the Customization Parameters section.

Ok, Double click on the G_BLINK_PERIOD generic parameter, this will open the parameter editor.

First, click on Visible in the Customization GUI, of course, we'll need to modify it on IP use in the BD !!

The tool provides a default Display name, usally I put the same string as the parameter's VHDL name. So change it to G_BLINK_PERIOD.

As this parameter has to be provided in 100Mhz clock cycle number unit, the user shall know it, just say it in the Tooltip. I used "Unit is 100Mhz clock cycle number". The tooltip will display when your mouse cursor passes over the parameter in the GUI.

The tool provided the right long type and proposed that the parameter is Editable in the GUI, fine !

Now click the Specify Range box to access the definition. Select Range of integer, and set the minimum to 10_000_000d for 10Hz and maximum to 100_000_000d for 1Hz.

And set the default value to 100_000_000.

Click Ok.

Just do the same for the 4 other parameters. As we don't need them in our application, just set them as NOT Visible in customization GUI.

Last step, in the Customization GUI section, just move the G_BLINK_PERIOD parameter in the Page 0 section, which let it appear on the right side window !

And there you go, our IP's GUI looks like this.

Stage 6

Ports and Interfaces Section

In this section we will find all the inputs/outputs defined in the IP's top level entity.

But the most important thing is that if your entity provides signals with names corresponding to a defined interface, the tool will automatically identify it and replace it with the interface view of the bunch of signals, thus reducing GUI's complexity !!!!

For our IP there are 3 standard interfaces :

- The AXI Lite Slave Interface
- The AXI reset in interface
- The AXI clock in interface

Stage 7

Addressing and Memory section

This section displays the memory mapping of the IP when the IP provides memory mapped interfaces.

You can specify the base address offset and the address range that will be decoded by the IP (Number of address bits in the implemented address decoder).

As all the provided parameters are generic parameters, they will be replaced by the values you will provide in the address editor in the Block Design editor when you use your IP.

Stage 8

As we used the Customization GUI section earlier, we will jump to the

Review and Package section

This is the final section !

You can read the summary and finally click Re-Package IP to generate your IP.

If you are re-Packaging an existing IP, just click to accept overwriting the existing project.

Then the IP packager tool closes and you're back in the IP catalog !

Post Conclusion

Waou ! This post was quite long, but IP customization can do many many things, so it is quite long to cover everything about it !

Now we have :

- Created a Custom IP Library.
- Used the wizzard to create an IP template structure.
- Customized the source code of the IP for our needs.
- Generated our custom IP in the custom IP Library