Edk ctt-13.3
Edk ctt-13.3
and Techniques
Revision History
The following table shows the revision history for this document.
EDK Concepts, Tools, and Techniques www.xilinx.com UG683 (v13.3) October 19, 2011
Chapter 1
Introduction
About This Guide
The Xilinx® Embedded Development Kit (EDK) is a suite of tools and Intellectual Property
(IP) that enables you to design a complete embedded processor system for implementation
in a Xilinx Field Programmable Gate Array (FPGA) device.
This guide describes the design flow for developing a custom embedded processing
system using EDK. Some background information is provided, but the main focus is on the
features of and uses for EDK.
Read this guide if you:
• Need an introduction to EDK and its utilities
• Have not recently designed an embedded processor system
• Are in the process of installing the Xilinx EDK tools
• Would like a quick reference while designing a processor system
Note: This guide is written for the Windows operating system. Linux behavior or the graphical user
interface (GUI) display might vary slightly.
Additional Documentation
More detailed documentation on EDK is available at:
http://www.xilinx.com/ise/embedded/edk_docs.html
Documentation on the Xilinx Integrated Software Environment (ISE®) is available at:
http://www.xilinx.com/support/software_manuals.htm.
Software Licensing
Xilinx software uses FLEXnet licensing. When the software is first run, it performs a license
verification process. If it does not find a valid license, the license wizard guides you
through the process of obtaining a license and ensuring that the Xilinx tools can use the
license. If you are only evaluating the software, you can obtain an evaluation license.
For more information about licensing Xilinx software, refer to the ISE Design Suite 13:
Installation and Licensing Guide:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_3/iil.pdf
Supported Boards
You can target one of the supported embedded processor development boards available
from Xilinx or one of its partners. When you have chosen among the peripherals available
on your selected board, the BSB creates a user constraints (UCF) file that includes pinouts
for the peripherals you selected. The UCF file contains functional default values that are
Selecting a Board pre-selected in Xilinx Platform Studio (XPS). You can further enhance this base-level
Type project in XPS and implement it with utilities provided by ISE®.
When you first install EDK, only Xilinx board files are installed. To target a third party
board, you must add the necessary board support files. The BSB Board Selection screen
contains a link that helps you find third party board support files. After the files are
installed, the BSB drop-down menus display those boards as well.
Custom Boards
If you are developing a design for a custom board, the BSB lets you select and interconnect
one of the available processor cores (MicroBlaze™ or PowerPC® processors, depending on
your selected target FPGA device) with a variety of compatible and commonly used
peripheral cores from the IP library. This gives you a hardware system to use as a starting
point. You can add more processors and peripherals, if needed. The utilities provided in
XPS assist with this, including the creation of custom peripherals.
Setting Up Software
The Software Development Kit (SDK) is required for software development, and you’ll
have the chance to try it as you work through this guide. Sample C applications used in
Software Debug Test Drives are generated in SDK.
a.*Supported simulators are listed in “Installation Requirements: What You Need to Run
EDK Tools,” page 6.
When you click Finish, the New Project Wizard closes and the project you just created
opens in ISE Project Navigator.
You’ll now use the New Source Wizard to create an embedded processor project.
1. Click the New Source button on the left-hand side of the Design Hierarchy window.
The New Source Wizard opens.
2. Use the information in the table below to make your selections in the wizard screens.
After you complete the New Project wizard, ISE recognizes that you have an
embedded processor system and starts XPS.
A dialog box opens, asking if you want to create a Base System using the BSB wizard.
3. Click Yes.
The first window of the BSB asks you to elect whether to create an AXI-based or PLB-
based system.
4. Select AXI system and click OK.
5. In the Base System Builder wizard, create a project using the settings described in the
following table. If no setting or command is indicated in the table, accept the default
values.
What’s Next?
The upcoming sections address Hardware Fundamentals.
• In Chapter 3, “Using Xilinx Platform Studio,” you will use the XPS software.
• In Chapter 4, “Working with Your Embedded Platform,” you will continue with the
hardware design and learn how you can view and modify your new project in XPS.
What is XPS?
XPS includes a software interface that provides a set of tools to aid in project design. This
chapter describes the XPS software and some of the most commonly used tools.
Using the XPS User The XPS main window is divided into these three areas:
Interface
• Project Information Area (1)
• System Assembly View (2)
• Console Window (3)
The XPS main window also has labels to identify the following areas:
• Connectivity Panel (4)
• View Buttons (5)
• Filters Pane (6)
Project Tab
The Project Tab, shown in Figure 3-2, contains information on the current project,
including important project files and implementation settings.
Figure X-Ref Target - Figure 3-2
IP Catalog Tab
The IP catalog tab is shown in Figure 3-3.
X-Ref Target - Figure 3-3
Connectivity Panel
With the Bus Interfaces tab selected, you see the Connectivity Panel (label 4 in Figure 3-1,
page 16), which is a graphical representation of the hardware platform connections. You
can hover your mouse over the Connectivity Panel to view available bus connections.
AXI interconnect blocks are displayed vertically, and a horizontal line represents an
interface to an IP core. If a compatible connection can be made, a connector is displayed at
the intersection between the interconnect block and the IP core interface.
The lines and connectors are color-coded to show bus compatibility:
• Connection symbols indicate whether IP blocks are masters or slaves.
• A hollow connector represents a connection that you can make.
• A filled connector represents an existing connection.
Click the connector symbol to create or disable a connection.
Filters Pane
XPS provides filters that you can use to change how you view the Bus Interfaces and Ports
in the System Assembly View. The filters are listed in the Filters pane (label 6 in Figure 3-1,
page 16) when the Bus Interfaces or Ports tabs are selected. Using these filters can unclutter
your connectivity panel when creating a design with a large number different buses.
Note: The Filters pane is collapsible along the right side of the System Assembly View.
View Buttons
The System Assembly View has two buttons to change how the data is arranged (label 5 in
Figure 3-1, page 16). You can use these buttons to sort information and revise your design.
• Change to Hierarchical/Flat View button
- The default display is called hierarchical view. The information that is displayed for
your design is based on the IP core instances in your hardware platform and
organized in an expandable tree structure.
- In flat view, you can sort the information alphanumerically by any column.
• Expand/Collapse All Tree Nodes button
The +/- icon expands or collapses all nets or buses associated with an IP to allow quick
association of a net with the IP elements.
Console Window
The Console window (label 3 in Figure 3-1, page 16) provides feedback from the tools
invoked during run time. Notice the three tabs: Console, Warnings, and Errors.
Start Up Page
The Start Up page has information relevant to XPS, including sets of links for release
information and design flows. There is also a tab to help you locate EDK documentation.
If the Start Up page isn’t already open, select Help > View Start Up Page to open it.
XPS Tools
XPS includes the underlying tools you need to develop the hardware components of an
embedded processor system.
Platgen
XPS includes the Hardware Platform Generation tool, Platgen, which generates HDL and
lower level netlists for the embedded processor system.
When you implement the FPGA design in Project Navigator, Platgen automatically runs if
necessary.
If you are running a multi-core CPU, you can make Platgen run faster by allowing
synthesis to run in parallel on multiple CPU cores. To enable the Parallel Synthesis option
in XPS, select Edit > Preferences > Synthesis and select the Parallel Synthesis check
box.
Simgen
XPS includes the Simulation Model Generation tool, Simgen, for generating simulation
models of your embedded hardware system based on your original embedded hardware
design (behavioral) or finished FPGA implementation (timing-accurate).
Simgen also provides simulation models for external memory and has automated support
to instantiate memory models in the simulation testbench.
Refer to the Embedded System Tools Reference Manual for information about external memory
simulation. You can find a link to this document in Appendix C, “Additional Resources.”
When you implement the FPGA design in Project Navigator, simulation is not available in
XPS. Use Project Navigator for simulation; it automatically invokes Simgen when
necessary.
Take a look at the directory structure XPS created and see how it could be useful as the
project development progresses.
Note: The files are stored in the location where you created your project file.
Figure X-Ref Target - Figure 3-4
Directory View
The BSB automatically creates a project directory with the name of your embedded system
source. This directory contains the subdirectories for your project in the repository search
path, shown in Figure 3-4:
__xps Contains intermediate files generated by XPS and other tools for
internal project management. You will not use this directory.
data Contains the user constraints file (UCF). For more information on this
file and how to use it, see the ISE® UCF help topics at:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx
13_3/manuals.pdf.
etc Contains files that capture the options used to run various tools.
implementation Contains the netlist and HDL wrapper files generated when Platgen
runs.
pcores Used for including custom hardware peripherals. The pcores
directory is described in more detail in Chapter 6, “Creating Your Own
Intellectual Property.”
In the main project directory, you will also find numerous files. Those of interest are:
system.xmp This is the top-level project design file. XPS reads this file
and graphically displays its contents in the XPS user
interface.
Project Navigator uses this file as the main source file for
the embedded processor system.
system.mhs The system Microprocessor Hardware Specification, or
MHS file, captures the system elements, their parameters,
and connectivity in a text format. The MHS file is the
hardware foundation for your project.
What’s Next?
Now that you know your way around XPS, you are ready to begin working with the
project you started. You’ll continue with Chapter 4, “Working with Your Embedded
Platform.”
4. In the Processes pane, double-click Generate Top HDL Source to generate the
wrapper file for the system.xmp file. This is now the top module for your project.
X-Ref Target - Figure 4-1
5. With the system_top file selected, double-click Generate Programming File in the
Processes pane to create your bitstream. It takes a few minutes and concludes with the
message:
Process “Generate Programming File” completed successfully
Generated Bitstream The generated bitstream file is located in the \implementation folder of your project
files and is called system.bit. There is another file generated called system_bd.bmm,
which SDK uses for loading memory onto your target board.
It is not necessary to add the constraint file (.ucf) generated by XPS to your project. Project
Navigator will automatically locate and use the constraints during implementation.
What’s Next?
Now you can start developing the software for your project using SDK. The next two
chapters explain embedded software design fundamentals.
About SDK
Some common terminology used when describing SDK operation includes:
• Workspace
• Software project
• Hardware platform
• Board support package
• Perspectives
• Views
SDK Terminology When you open SDK, you create a workspace. A workspace is a directory location used by
SDK to store project data and metadata. You must provide an initial workspace location
when SDK is launched. You can create multiple workspaces to more easily manage
multiple software versions.
A software project contains one or more source files, along with the necessary header files, to
allow compilation and generation of a binary output (.elf) file. A workspace can contain
multiple software projects. Each software project must have a corresponding board support
package.
You must have a hardware platform for your design. The hardware platform is the
embedded hardware design that is created in XPS. The hardware platform includes the
XML-based hardware description file, the bitstream file, and the BMM file. When you
import the XML file into SDK, you import the hardware platform. Multiple hardware
platforms can exist in a single workspace.
A board support package (BSP) is a collection of libraries and drivers that form the lowest
layer of your application software stack. Your software applications must link against or
run on top of a given board support package using the provided Application Program
Interfaces (APIs).
You can have SDK create board support packages for two different run-time environments:
Board Support • Standalone - A simple, semi-hosted and single-threaded environment with basic
Package Types in features such as standard input/output and access to processor hardware features.
SDK
• Xilkernel - A simple and lightweight kernel that provides POSIX-style services such
as scheduling, threads, synchronization, message passing, and timers.
In SDK, multiple board support packages can exist simultaneously. For example, you
might have a BSP for a design that runs on the standalone environment, and one that uses
Xilkernel.
Perspectives and SDK looks different depending on what activity you are performing. When you are
Views developing your C or C++ code, SDK displays one set of windows. When you are
debugging your code on hardware, SDK appears differently and displays windows
specific to debugging. When you are profiling code, you use the gprof view. These
different displays of windows are called perspectives.
8. Click Finish.
SDK creates the hardware platform and opens the New Xilinx C Project window.
9. Select the “Hello World” Sample Project Template. The Project name fills in
automatically with hello_world_0.
10. For the project location, make sure that the Use default location check box is selected
and click Next.
11. Select the Create a new Board Support Package project option and leave the default
options as they are set.
12. Click Finish.
The hello_world_0 sample application builds automatically, producing an ELF file
suitable for downloading onto the target hardware.
SDK displays your new hardware project with several panels. The most notable of these
panels are the Project Explorer, which at this time only displays your hardware platform,
and the system.xml file, which opens in its own view. Take a moment to review the
contents of the system.xml file.
Double-click the lscript.ld file to view the linker script contents in the text editor. If
you are familiar with the intricacies of linker scripts, you can make changes by selecting
Xilinx Tools > Generate Linker Script.
You now have a complete framework for editing, compiling, and building a software
project. The next step is debugging, which you will do in the next Test Drive.
4. Open a terminal emulation program and set the display to 9600 baud, 8 bit data, 1 stop
bit. Be sure to set the COM port to correspond to the COM port that the Silicon Labs
driver is using.
The Debug 5. In the Debug Perspective, the C code is now highlighted at the first executable line of
Perspective code (you might need to scroll to view helloworld.c). The debug window shows that
for Thread[0] the main() function is currently sitting at line 30 because there is an
automatically-inserted breakpoint.
Note: If your display does not show line numbers, you can turn them on by right-clicking in the
left margin of the helloworld.c window and selecting Show Line Numbers.
6. Execute the code by clicking the Resume button or pressing F8 on your keyboard.
The output in the terminal window displays Hello World.
7. Terminate the debug session by clicking the Terminate button or pressing Ctrl + F2.
SDK Drivers
The “low-level” drivers that Xilinx provides are located in the \EDK\sw\
XilinxProcessorIPLib\drivers directory of your EDK installation area. Here, you
will see a directory for each peripheral's driver. There are drivers corresponding to each
piece of hardware available to you in Platform Studio. For each driver, the directory
contains source code, HTML documentation on the driver, and examples of how the
drivers can be used.
You can also view information about Application Programming Interface (API)
documentation for each device driver in your install directory: <ISE install
area>\EDK\doc\usenglish\xilinx_drivers.htm.
SDK Windows
As demonstrated in the previous chapter, SDK has different predefined sets of display
windows, called perspectives.
Whether you are working in the C/C++ Perspective or the Debug perspective, you'll find
the SDK windowing system very powerful. There are two kinds of windows within
perspectives: editing windows and informational windows. The editing windows, which
contain C or C++ source code, are language-specific and syntax aware. Right-click an item
in an editing window to open a comprehensive list of actions that can be done on that item.
Informational windows are particularly flexible. You can have as many informational
windows as you like. An informational window can have any number of views, each of
which is indicated by a tab at the top of the window. Views in the Debug perspective
include Disassembly, Register, Memory, and Breakpoints.
Views can be moved, dragged, and combined in any number of ways. Click any tab on any
window in either the C/C++ or Debug Perspective or drag it to another window. Its
contents are displayed in the new window. To see the views available for a given
perspective, select Window > Show View.
Experiment with moving windows around. The ability to easily customize your
development and debug environment is one of the more powerful features of SDK. SDK
remembers the position of the windows and views for your perspective within a project.
6. Save and close the file, and observe that it, too, builds automatically.
Note: You can turn automatic building on and off by selecting Project > Build Automatically.
SDK will error out, because it has no knowledge of where the peripheral test or
memory test functions are. (They're in their own C Projects). We will now drag and
drop the relevant source files to hello_world_0 so that helloworld.c can access
them.
7. Drag and drop source files from memory_tests_0 and peripheral_tests_0 into
the src subfolder of the hello_world_0 folder. Figure 5-4 shows the source files that
the directory should contain.
As you drag and drop the files, hello_world_0 builds after each file. After you've
dropped the last file and the ELF file successfully builds, the following message
displays in the Console View:
Invoking: MicroBlaze Print Size
mb-size hello_world_0.elf |tee "hello_world_0.elf.size"
text data bss dec hexfilename
40234 512 5598 46344 b508hello_world_0.elf
Finished building: hello_world_0.elf.size
Note: If you don’t see this message, click one of the source files you just moved.
Note the size: 46344 (decimal). Up until now, our applications have all run from block
RAM, which is memory on the FPGA. Recall from Chapter 3 and Chapter 4 that we
have 32K of instruction memory local to the MicroBlaze™ processor. Our application
has grown to 46K, meaning some of it will have to reside in external RAM. The
problem is that the RAM test is destructive: if part of the application is in external
RAM, it could crash. So next you’ll fix that problem before it occurs.
8. Open memorytest.c and scroll down to memorytest_main().
9. Position the cursor over &memory_ranges[i]. An informational window opens to
display information about memory_ranges. You can click in the window and scroll
up and down. Note that memory_ranges contains the starting address and size (in
decimal) of each memory to be tested.
10. Click on memory_ranges and then right-click and select Open Declaration to open
the memory_config_g.c file, in which memory_ranges is defined. Note that
whenever a C file opens for editing, the Outline window, if visible, shows the variables
and header files used with the C file. You can right-click any variable in the outline
view to view a call hierarchy that shows the calling path back to main().
11. To change where the external memory test starts, modify the data structure in
memory_config_g.c as follows:
{
"MCB_DDR3",
"axi_s6_ddrx",
0xc1000000, /*Change from 0xc0000000 to 0xc1000000*/
134217728,
},
12. Save and close the file. It recompiles without errors.
13. Run the hello_world_0.elf application. Confirm that it runs correctly. The
terminal window displays a message to indicate that both the memory test and the
peripheral test are working.
As you can see, the MicroBlaze processor is currently sitting at the beginning of
main() with program execution suspended at line 0xc00001bc. You can correlate
that with the Disassembly view, which shows the assembly-level program execution
also suspended at 0xc00001bc. Finally, the helloworld.c window also shows
execution suspended at the first executable line of C code. Select the Registers view to
confirm that the program counter, RPC register, contains 0xc00001bc.
Note: If the Registers window isn't showing, select Window > Show View > Registers.
2. Double-click in the margin of the helloworld.c window next to the line of code that
reads peripheraltest_main();. This sets a breakpoint at
peripheraltest_main().
To confirm the breakpoint, review the Breakpoints window.
Note: If the Breakpoints window is not showing, select Window > Show View > Breakpoints.
3. Select Run > Resume to resume running the program to the breakpoint.
Program execution stops at the line of code that includes
peripheraltest_main();. Disassembly and the debug window both show
program execution stopped at 0xc00001dc.
4. Select Run > Step Into to step into the peripheraltest_main() routine. Program
execution is suspended at location 0xc0000634. The call stack is now 2 deep.
5. Select Run > Resume again to run the program to conclusion. When the program
completes running, the Debug window shows that the program is suspended in a
routine called exit. This happens when you are running under control of the
debugger. Review your terminal output, which indicates that both
peripheraltest_main() and memorytest_main() have run.
6. Re-run your code several times. Experiment with single-stepping, examining memory,
breakpoints, modifying code, and adding print statements. Try adding and moving
views.
7. Close SDK.
What’s Next?
The goal of this chapter was to provide you a C project with multiple files to work with,
and enough exposure to the debugger to experiment and customize SDK to work the way
you do.
In the next chapter, you will create your own IP.
Overview of IP Creation
The XPS System Assembly View (shown in Figure 3-1, page 16) shows connections among
buses, AXI devices, processors, and IP. Any piece of IP you create must be compliant with
the system you design.
To ensure compliance, you must follow these steps:
1. Determine the interface required by your IP. The bus to which you attach your custom
peripheral must be identified. For example, you could select one of the following
interfaces:
- AXI4-Lite: Simpler, non-burst control register style interface. You should use
AXI4-Lite for most simple, register based peripherals that only require single beat
transfers.
- AXI4: Burst Capable, high-throughput memory mapped interface. AXI4 provides
high performance burst transfers, and you should use it when high speed access
to and from memory systems is required.
- Processor Local Bus (PLB) version 4.6. The PLBv46 provides a high-speed
interface between a PowerPC® processor and high-performance peripherals.
- Fast Simplex Link (FSL). The FSL is a point-to-point FIFO-like interface. It can be
used in designs using MicroBlaze™ processors, but generally is not used with
PowerPC processor-based systems.
2. Implement and verify your functionality. Remember that you can reuse common
functionality available in the EDK peripherals library.
3. Verify your standalone core. Isolating the core ensures easier debugging in the future.
4. Import the IP to EDK. Your peripheral must be copied to an EDK-appropriate
repository search path. The Microprocessor Peripheral Definition (MPD) and
Peripheral Analyze Order (PAO) files for the Platform Specification Format (PSF)
interface must be created, so that the other EDK tools can recognize your peripheral.
5. Add your peripheral to the processor system created in XPS.
After the Welcome page, the Peripheral Flow page opens. On this page, you can either
create a new peripheral or import an existing peripheral.
Figure X-Ref Target - Figure 6-1
2. Select Create templates for a new peripheral. Before continuing through the wizard,
read through the text on this page.
Note: Each CIP wizard screen is full of useful information. You can also click More Info to view
the related XPS help topic.
3. On the Repository or Project page, specify where to store the custom peripheral files.
For this example, you will use this peripheral for a single embedded project.
4. Select To an XPS project.
Because you launched the CIP wizard from within XPS, the directory location is
automatically filled in.
Note: If the custom pcore will be used for multiple embedded projects, you can save the file in
an EDK repository.
5. Use the Name and Version page to indicate the name and version of your peripheral.
For this example design, use the name blink.
Figure X-Ref Target - Figure 6-2
A version number is supplied automatically. You can also add a description of your
project.
6. On the Bus Interface page, select the interconnection or bus type that connects your
peripheral to your embedded design. For this example, select AXI4-Lite.
Note: You can access related data sheets from the Bus Interface page.
Figure X-Ref Target - Figure 6-3
7. On the IPIF (IP Interface) Services page, indicate the IPIF services for your peripheral.
Figure X-Ref Target - Figure 6-4
Because User Logic Software Register was selected in the IPIF Services page, the User
Software Accessible Registers page opens.
8. Leave the default value of 1 selected.
X-Ref Target - Figure 6-5
9. On the IP Interconnect (IPIC) page, review the set of IPIC signals that the CIP wizard
offers for your custom peripheral. If you don’t understand what these signals do,
review the appropriate specification. The signals selected should be adequate to
connect most custom peripherals.
Figure X-Ref Target - Figure 6-6
On the Peripheral Simulation Support page, you can elect to have the CIP generate a BFM
simulation platform for your project.
Figure X-Ref Target - Figure 6-7
Generating BFM A BFM simulation requires a license for the AXI BFM Simulation model. For more
simulation platform information about using AXI BFMs for embedded designs with XPS, refer to AXI Bus
Functional Models v1.9 (DS824). AXI BFM simulation also requires a supported
simulator: ISim, ModelSim-SE/PE, Questa Simulator, or IES.
If you think you might want to run a BFM simulation on this IP example, generate the
BFM platform now.
Note: AXI BFM simulation must be licensed. An AXI BFM license is not included with the ISE
Design Suite installation. You can purchase the license through the Xilinx Sales Channel, then
obtain it at http://www.xilinx.com/getlicense.
The CIP wizard creates two HDL files that implement your pcore framework:
- The blink.vhd file - the file that contains the AXI interface logic. Assuming your
peripheral contains ports to the outside world, you must modify this file to add
the appropriate port names. This file is well documented and tells you exactly
where to add the port information.
If you are a Verilog designer, don’t panic, but realize that you must write the port
names using HDL syntax. For this example, you can find the source code in an
upcoming Test Drive and use that source as a template for future pcore creation.
- The user_logic.vhd file - the template file where you add the custom Register
Transfer Level (RTL) that defines your peripheral. Although you can create
additional source files, the simple design example you are using requires only the
user_logic.vhd file.
The Peripheral Implementation Support page lists three options for creating optional
files for hardware and software implementation.
Figure X-Ref Target - Figure 6-8
Verilog Support The CIP wizard can create the user_logic template in Verilog instead of VHDL. To
create the template in Verilog, select the Generate stub ‘user_logic’ template in
Verilog instead of VHDL check box.
If you intend to implement your pcore design to completion (for timing analysis or
timing simulation), click the Generate ISE and XST project files to help you
implement the peripheral using XST flow check box. The CIP wizard creates the
necessary ISE project files. However, if your peripheral is low-speed or very simple,
this step is not necessary.
If your peripheral requires more complex software drivers, click the Generate
template driver files to help you implement software interface check box. The CIP
wizard creates the necessary driver structure and some prototype drivers based on the
services selected.
For this example design, leave all three boxes unchecked. The final screen displays a
summary of the CIP wizard output, including the files created and their locations.
10. Review this information and click Finish. You can observe the file creation status in the
Console window.
Figure X-Ref Target - Figure 6-9
5. Scroll down to approximately line 304. In the code segment shown here, the user port
LEDs are displayed in the appropriate location. Add the LEDs port declaration into the
user_logic port mapping in your file as shown here.
Figure X-Ref Target - Figure 6-12
9. Scroll down to approximately line 133, and add this signal declaration.
X-Ref Target - Figure 6-14
10. Scroll down to approximately line 214 and add the following code, beginning with
-- Create counter. This code implements the counter logic, and connects the
register bit to control counter operation.
X-Ref Target - Figure 6-15
All the code described here is simple and can be modified if you want to experiment later.
However, the interface signals in lines 208-210 are required to have very explicit behavior.
Incorrect logic driving these signals will cause the custom pcore to interfere with proper
bus operation, and could result in unexpected behavior during debug.
IP2Bus_Data is read by the processor during a read operation. For this simple peripheral,
the data last written to the peripheral control register can also be read back.
The final signal, IP2Bus_WrAck, is also critical. IP2Bus_WrAck is a write acknowledge
that must be returned by the custom logic. IP2Bus_WrAck must be driven high only for a
single cycle, but can be delayed if your custom logic needs to add wait states to the
response. For this example, no wait states are necessary. Connecting IP2Bus_WrAck
directly to slv_write_ack provides a simple, zero wait state response. The logic for the
read acknowledge signal is identical. The peripheral can add wait states if necessary.
The IP2Bus_Error is driven with a constant logic zero, implying that no error condition is
returned. If your custom peripheral could potentially time out based on having to wait for
other external logic, you can connect logic to drive IP2Bus_Error to terminate the bus
transfer.
5. In the System Assembly View, right-click LEDs_4Bits and select Delete Instance.
The Delete IP Instance dialog box appears:
Figure X-Ref Target - Figure 6-16
6. Accept the default setting. You’ll add the external ports back into the design manually.
7. Locate the blink pcore in the IP Catalog, right-click the pcore, and select Add IP.
The XPS Core Config dialog box opens automatically.
8. Accept all defaults and click OK to close the dialog box.
The Instantiate and Connect IP window opens.
9. Accept the defaults and click OK.
XPS adds the IP to the System Assembly View. You can see it in the Bus Interfaces tab.
Figure X-Ref Target - Figure 6-17
The blink core is now added to the embedded system. However, you must make the
external connections between blink and the LEDs on the evaluation board.
10. Click the Ports tab, expand blink_0, right-click LEDs, and select Make External.
A default name of blink_0_LEDs_pin was assigned as the External Ports name.
To change the assigned net and pin names, click in the Connected Port column,
respectively. Alternatively, you can manually edit the MHS file. For now, don’t change
the assigned names.
11. Click the Addresses tab and verify that the address range for blink_0 is
0x7C600000 - 0x7C60FFFF.
If it seems strange for a simple peripheral to be assigned a 64Kbyte address space,
don’t worry. A wider address space requires decoding of fewer address lines. In an
FPGA, a decoder with many inputs is implemented as a cascade of lookup tables.
The deeper the cascade, the slower the operating frequency. By assigning wide
peripheral address ranges, the resulting FPGA implementation runs faster.
The final step is to update the UCF constraints file to assign the LED outputs to the
proper FPGA pins.
12. Click the Project tab and double-click the system.ucf file to open it in the XPS main
window.
13. Look for LEDs_4Bits_TRI_O. These pin assignments were left in the UCF even
though you earlier deleted the GPIO pcore. It is important to note that removing a
pcore does not automatically trigger an update to the UCF file.
14. Replace LEDs_4Bits_TRI_O with blink_0_LEDs_pin in all four locations and save
the UCF file.
Congratulations, you have created and added a custom pcore!
15. Close XPS.
Generating Video IP
Generating Video IP in the proper format for import in XPS is only a matter of selecting the
correct output format in CORE Generator.
The CORE Generator IP Catalog, by default, is sorted by functionality. Video IP is located
in the Video & Image Processing folder.
X-Ref Target - Figure B-1
The next time you launch XPS, the Image Characterization IP appears in the XPS IP
Catalog.
X-Ref Target - Figure B-3
Note: If you had XPS open when you added the IP, you can update the IP Catalog by selecting
Project > Rescan User Repositories.
Note: The directory location must be two levels above the pcore directory. For this example,
the search path is in the Video2 folder.
X-Ref Target - Figure B-5
Note: The directory location must be two levels above the pcore directory. For this example,
the search path is Video3.
X-Ref Target - Figure B-8
Additional Resources
Xilinx Resources
• ISE® Design Suite: Installation and Licensing Guide (UG798):
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_3/iil.pdf
• ISE Design Suite Release Notes Guide (UG631):
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_3/irn.pdf
• Xilinx® Documentation:
http://www.xilinx.com/support/documentation
• Xilinx Glossary:
http://www.xilinx.com/support/documentation/sw_manuals/glossary.pdf
• Xilinx Support: http://www.xilinx.com/support.htm
EDK Documentation
The following documents are available in your EDK install directory, in
<install_directory>\doc\usenglish. You can also access the entire
documentation set online at: http://www.xilinx.com/ise/embedded/edk_docs.htm.
• Embedded System Tools Reference Manual (UG111):
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_3/est_rm.pdf
• Platform Specification Format Reference Manual (UG642):
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_3/psf_rm.pdf
• MicroBlaze™ Processor User Guide (UG081):
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_3/
mb_ref_guide.pdf
• SDK Help
• XPS Help