1. Xilinx University Program
Embedded Design Flow
Xilinx University Program

2. After completing this workshop, you will be able to:
Objectives
After completing this workshop, you will be able to:
Describe the various tools that encompass Xilinx Embedded Development Kit (EDK)
Rapidly architect an embedded system containing an IBM PowerPC processor and Xilinx-supplied IP cores
Create and Integrate your own custom peripheral
Develop and debug software applications with the Eclipse-based Software Development Kit (SDK)

3. Outline Basic Hardware System Adding IP to a Hardware Design
The course consists of the following modules:
EDK Overview
PowerPC Hardware Design
Basic Hardware System
Hardware Design Using EDK
Adding IP to a Hardware Design
Adding Your Own IP to the System
Debugging with SDK
The EDK Overview module introduces the EDK. The embedded system design overview includes the need, methodology, and tools available for a hardware/software co-design, development, and debugging. Two methods of creating a hardware system from scratch are exemplified. Supported operating systems and integrated tools are listed.
The Hardware Design module introduces the basic terms and identifies various buses available in PowerPC-based and MicroBlaze-based system designs. Each bus is then explained in detail with some of the implementation details. Both MicroBlaze and PowerPC CPU architectures are introduced from the viewpoint of the programmer. Vector tables for both types of processors are covered next, followed by detailed coverage of various configurations in MicroBlaze and the JTAG-chain in PowerPC.
The Adding a Processor System to and FPGA Design module introduces the two design flows of a hardware system available in EDK: the XPS flow and the ISE flow. The procedure involved in each flow is illustrated. This module also introduces an UltraController design as an example of adding a processor system using ISE flow.
The Adding Your Own IP to the OPB Bus module introduces how to develop your own custom IP and integrate it into XPS by using the Importing IP Wizard tool. This module covers that specific feature of the EDK. The OPB bus, bus transactions, and IP cores are described in detail.

4. PowerPC-Based Labs 1 through 6
OPB
Bus
PLB
Bus
UART
GPIO
DIP SW
Push Buttons
PLB2OPB
PPC
MY IP
LEDs
PLB BRAM
Cntlr
PLB BRAM
Timer
PLB BRAM
Cntlr
PLB BRAM
INTC
ICON
IBA

5. Embedded Development Tool Flow Overview
Data2MEM
Download Combined
Image to FPGA
Compiled ELF
Compiled BIT
RTOS, Board Support Package
Embedded
Development Kit
Instantiate the
‘System Netlist’
and Implement
the FPGA ?
HDL Entry
Simulation/Synthesis
Implementation
Download Bitstream
Into FPGA
Chipscope
Standard FPGA
HW Development Flow
VHDL or Verilog
System Netlist
Include the BSP
and Compile the
Software Image
Code Entry
C/C++ Cross Compiler
Linker
Load Software
Into FLASH
Debugger
Standard Embedded
SW Development Flow
C Code
Board Support
Package 1 2 3
While seemingly complex when viewed in total, the system design flow simply combines the standard hardware flow used to create FPGA bitstreams and standard software flow used to create processor ELF files. In fact, unless on-chip memory resources are used to store the software image, the Embedded Developers Kit can be viewed as nothing more than an extension to the Xilinx core generation tool CoreGen.
The first step is to create the ‘System Netlist’ using the Embedded Developers Kit and instantiate that netlist into the design’s HDL code. The hardware design is then synthesized, merged and implemented using the exact same flow as used with any other ‘black box’ core. While it is common to include a portion of the yet created software image inside the FPGA using block RAM, the ‘Compiled BIT’ file created during this phase of development only contains the systems hardware description.
The second step is to create the ‘Board Support Package’ (BSP) using the Embedded Developers Kit (EDK) and include the required drivers in the system’s C code. The code is then compiled and linked with the various functions available in the BSP as is the same with any other processor system. Because the embedded system is built using the FPGA fabric, the BSP is customized for the particular set of peripherals included in the ‘System Netlist’. Unlike an off the shelf general purpose processor, Virtex-II Pro embedded systems can include any combination of Xilinx provided and user created peripherals. This means that every BSP is potentially unique and as such EDK is tasked with customizing a generic set of drivers as required to properly support the ‘arbitrary processor system’.
Once the final set of peripherals and bus structures have been solidified, the software and hardware flows can be run independently. Even if part or all of the software image is stored using on-chip block RAM, the software flow does not require running the hardware flow from scratch when making software changes. Only if a change is made to the instantiated ‘System Netlist’ does the hardware need to be implemented again before a the new software image which relies on the architectural change can be loaded and run.
If the software image is completely stored externally, configuring the FPGA and loading the external storage device are performed in exactly the same way as a typical two chip solution. If part or all of the software image is stored using on-chip block RAM and as such is embedded within the FPGA’s bitstream, an additional step is required before the FPGA can be configured. EDK provides a tool called Data2MEM which merges the appropriate sections of the ‘Compiled ELF’ file with the ‘Compiled BIT’ file. The resulting BIT file is created is typically created in a few seconds and can then be used to configured the FPGA. When the entire software image is stored within the FPGA, only the BIT file is needed to both configure the system and load the software image. If only portion of the software image, such as the bootstrap, is stored within the FPGA, then Data2MEM is run to create a combined BIT file and the system is once again configured/loaded as any two chip solution using the unmerged ELF sections and the combined BIT file.
Debugging the software running on the system is performed in the same manner as would be on any general purpose processor. GDB or other debug tool is used to connect to the target and provide runtime control of the target and even load new images when desired. Unlike general purpose processors, the physical system can be probed using ChipScope modules. This capability provides a level of visibility into the operation of the system unmatched by external processors.

6. EDK Tool Flow Simulation Generator Hardware Platform Generation
Library Generation
Embedded Software
Development
ISE Tools
IP Library or User Repository
MSS
LibGen .a
Compiler (GCC) .o
Linker (GCC)
ELF
MHS
PlatGen
Drivers, MDD
MPD, PAO
PCore HDL
System and Wrapper VHD
system.BMM
Synthesis (XST)
NGC
NGDBuild
UCF
NGD
MAP
NCD, PCF
PAR
NCD
BitGen
system.BIT
BitInit
download.BIT
iMPACT
system_BD.BMM
SimGen
Behavioral VHD Model
Structural VHD Model
Timing VHD Model
IP Models
ISE Models
Testbench Stimulus
CompEDKLib
CompXLib
Application Source .c, .h, .s
download.CMD
EDK SW Libraries

7. Xilinx Platform Studio (XPS)
The Console Window (1)
The Console Window acts as a console for output, warning, and error messages from XPS and from other tools invoked by XPS. Error, warning, and output messages are separated in tabbed windows. Click the Error and Warning links to open associated answer records. If you right-click or double-click an error that has an associated file name and line number, you can navigate to that file in the editor.
The Project Information Area (2) -The Project Information Area has three tabs:
Project Tab (4)
Project Files — This category includes all project-specific files: MHS, MSS, UCF, iMPACT Command files, Implementation Option files, and Bitgen Option files.
Project Options — This category includes all project-specific options: Device, Netlist, Implementation, HDL, and Sim Model. Double-click or right-click any entry to open the Project Options dialog box, where changes can be made.
Reference Files — This category includes all log and output files produced by the various XPS implementation processes. Double-click or right-click any entry to view a specific file in the XPS text editing window.
Applications Tab (5)
The Applications tab opens the Application Explorer. The Application Explorer lists all software application option setting, header files and source files associated with each application project. Double-click Add Software Application Project to create a new software application project. Each project must be associated with a processor in hardware. Right-click a software application project entry to build, clean or delete the project. You can set the compiler option for the project or generate the linker script. You can also mark the project as the image to load the BRAM during device initialization.
Notes continues to next slide …

8. Merging Hardware and Software Flows
data2MEM
download.bit
MicroBlaze™/ PPC
UART
Arbiter
GPIO

9. Merging Hardware and Software Flows
Data2MEM – Update the bitstream
Input files → system_bd.bmm, system.bit, executable.elf
Output file → download.bit
This invokes the BitInit tool, which initializes the instruction memory of the processor
The instruction memory may be initialized with a bootloop, bootloader, or an actual application
Now the hardware and the software flows come together. This stage also calls the hardware and software flow tools if required
This is the stage where the hardware and the software flows come together. This stage also calls the hardware and software flow tools if required
The Data2MEM utility provided in the ISE™ software is called to initialize the FPGA block RAMs with the desired software (bootloop, bootloader, or an actual application)
The bootloop is used when the application will be downloaded using xmd. The bootloader is used when the actual application is stored in external non-volatile memory and it needs to be loaded into an external volatile memory. The actual application is used in the blockRAM only when the application is small enough to fit in it.
At the end of this stage, users get the download.bit file, which contains information regarding both the software and the hardware part of the design

10. Download the bitstream
Configuring the FPGA
Download the bitstream
Input file → download.bit
This downloads the download.bit file onto the target board using the Xilinx iMPACT tool in batch mode
XPS uses the etc/download.cmd file for downloading the bitstream
The download.cmd file contains information such as the type of cable is used and the position of the FPGA in a JTAG chain

11. Glossary of Tools and Files
Reference
Glossary of Tools and Files
A few of the files the EDK tools generate:
MDD = Microprocessor Driver Description
MHS = Microprocessor Hardware Specification
MPD = Microprocessor Peripheral Description
MSS = Microprocessor Software Specification
PAO = Peripheral Analyze Order
BBD = Black Box Definition
BMM = Block RAM Memory Map

12. Glossary of Tools and Files
Reference
Glossary of Tools and Files
Some of the EDK tools:
LibGen = Library Generator. Uses MSS file, copies device drivers source files and generates software libraries for the defined system
PlatGen = Platform Generator. Uses the MHS and MPD files to create an implementation netlist of a bus-based sub-system
SimGen = Simulation Generator. Uses MHS file to configure and generate a simulation netlist pointing to various simulation model types, such as SWIFT, BFM, netlist, RTL, etc.

13. MPD File
Microprocessor Peripheral Definition file provides default parameter settings in XPS
## MPD file created automatically for design OPB_SEMAPHORE BEGIN opb_pwm, IPTYPE=PERIPHERAL ## Parameter list for the generics PARAMETER C_OPB_AWIDTH = 32, DT = integer PARAMETER C_OPB_DWIDTH = 32, DT = integer PARAMETER C_BASEADDR = 0xFFFF8000, DT = std_logic_vector PARAMETER C_HIGHADDR = 0xFFFF80FF, DT = std_logic_vector PARAMETER C_NO_CHANNELS = 4, DT = integer PARAMETER C_MAX_RESOLUTION = 16, DT = integer OPTION SIM_MODELS = BEHAVIORAL : STRUCTURAL BUS_INTERFACE BUS=SOPB, BUS_STD=OPB, BUS_TYPE=SLAVE
Parameters override generics in VHDL
entity OPB_PWM is
generic (
C_OPB_AWIDTH : integer := 32;
C_OPB_DWIDTH : integer := 32;
C_BASEADDR : std_logic_vector(0 to 31) := X"FFFFA000";
C_HIGHADDR : std_logic_vector := X"FFFFA0FF";
C_NO_CHANNELS : integer range 0 to := 4;
C_MAX_RESOLUTION : integer range 4 to 32 := 16 );

14. MPD File
Microprocessor Peripheral Definition file provides default connections in XPS
## Port list for the signals
## Global signals
PORT OPB_Clk = "", DIR = in, SIGIS=CLK, BUS=SOPB
PORT OPB_Rst = OPB_Rst, DIR = in, BUS=SOPB
## OPB signals
PORT OPB_ABus = OPB_ABus, DIR = in, VEC = [0:31], BUS=SOPB
PORT OPB_BE = OPB_BE, DIR = in, VEC = [0:3], BUS=SOPB
PORT OPB_RNW = OPB_RNW, DIR = in, BUS=SOPB
PORT OPB_select = OPB_select, DIR = in, BUS=SOPB
PORT OPB_seqAddr = OPB_seqAddr, DIR = in, BUS=SOPB
PORT OPB_DBus = OPB_DBus, DIR = in, VEC = [0:31], BUS=SOPB
PORT PWM_DBus = Sl_DBus, DIR = out, VEC = [0:31], BUS=SOPB
PORT PWM_errAck = Sl_errAck, DIR = out, BUS=SOPB
PORT PWM_retry = Sl_retry, DIR = out, BUS=SOPB
PORT PWM_toutSup = Sl_toutSup, DIR = out, BUS=SOPB
PORT PWM_xferAck = Sl_xferAck, DIR = out, BUS=SOPB
PORT PWM = "", DIR = out, VEC = [0:C_NO_CHANNELS-1]
END
OPB Bus Signals
port (
-- Global signals
OPB_Clk : in std_logic;
OPB_Rst : in std_logic;
-- OPB signals
OPB_ABus : in std_logic_vector(0 to 31);
OPB_BE : in std_logic_vector(0 to 3);
OPB_RNW : in std_logic;
OPB_select : in std_logic;
OPB_seqAddr : in std_logic;
OPB_DBus : in std_logic_vector(0 to 31);
Slave Signals
PWM_DBus : out std_logic_vector(0 to 31);
PWM_errAck : out std_logic;
PWM_retry : out std_logic;
PWM_toutSup : out std_logic;
PWM_xferAck : out std_logic;
PWM : out std_logic_vector(0 to C_NO_CHANNELS-1) );

15. What does the PlatGen tool do?
Review
What is the MHS file?
The MHS file is the Microprocessor Hardware Specification; it specifies processors, hardware peripherals, bus connections, and address spaces for the hardware
What does the PlatGen tool do?
PlatGen takes the MHS file and creates the system and peripheral netlists, HDL wrapper files, BMM file, etc.
What tool is used to place executable code in an FPGA block RAM?
The Data2Mem tool will take the BMM file and create the proper initialization for the block RAM that is assigned to the executable memory space

16. Review What does the LibGen tool do?
Read MSS file and generate libraries
What is the difference between system.bit and download.bit files?
The system.bit file contains only hardware description whereas download.bit file contains both hardware description as well as executable software

17. Where Can I Learn More? Tool documentation
Getting Started with the Embedded Development Kit
Processor IP Reference Guide
Embedded Systems Tools Guide
Xilinx Drivers
Processor documentation
PowerPC Processor Reference Guide
PowerPC 405 Processor Block Reference Guide
MicroBlaze Processor Reference Guide
Support Website
Tech Tips:
EDK Website:

18. Adding Your Own IP to the System

19. Overview
Peripherals are connected to the microprocessor by using the data and address buses
Xilinx has implemented IBM's CoreConnect bus architecture
On-chip Peripheral Bus (OPB) version 2.1 of the CoreConnect architecture is designed for easy connection of on-chip peripheral devices
Any custom peripheral that connects to the OPB bus must meet the principles of the OPB protocol and the requirements of the Platform Generator

20. BBD File FILES Blackbox.ngc
The Black Box Definition (BBD) file identifies netlist files used for a user peripheral
The netlists are copied into the project/implementation directory
Example of a single file without options
FILES
Blackbox.ngc
Example of multiple file selections without options
blackbox1.ngc, blackbox2.ngc, blackbox3.edn
The Black Box Definition (BBD) file manages the file locations of optimized hardware netlists for the black-box sections of your peripheral design. The BBD format is a look-up table chart that lists netlist files. The first line is the header of the look-up table. There can be as many entries as necessary in the header to make a selection. Header entries are tailored by MPD parameters. The last column of the table must be the FILES column.

21. File Usage There are two ways to integrate your own IP into XPS
As a blackbox
Synthesized with XST or a third-party synthesis tool
Requires MPD and BBD
As HDL
Synthesized with the rest of the processor system
Uses XST
Requires MPD and PAO

22. Example of a BBD File with multiple file selections
C_FAMILY
C_RPM
C_FPU_TYPE
FILES
virtex2
true
full
opb_fpu_full.edf
lite
opb_fpu_lite.edf
virtex2p
virtex
false
opb_fpu_full_noram32x1d.edf, ram32x1ds.edf
opb_fpu_lite_noram32x1d.edf, ram32x1ds.edf
The Black Box Definition (BBD) file manages the file locations of optimized hardware netlists for the black-box sections of your peripheral design. The BBD format is a Look-Up Table (LUT) chart that lists netlist files. The first line is the header of the LUT. There can be as many entries as necessary in the header to make a selection. Header entries are tailored by MPD parameters. The last column of the table must be the FILES column.

23. Free Cores Included as VHDL Source with EDK (even more are now free)
Bus
fsl, lmb
opb
dcr, ocm, plb, fcb
Bus Bridge
opb2opb, opb2dcr, opb2plb
fcb2fsl, plb2opb
Communication
opb_spi
hard_temac, plb_temac
Debug
icon, iba, ila, vio, mdm
Iba, jtagppc_cntlr
GPIO
opb_gpio
plb_gpio
Interrupt Controller
opb_intc
dcr_intc
Memory Controller
mch_opb_ddr, mch_opb_sdram, opb_bram, opb_ddr, opb_emc, opb_sdram, opb_sysace
dsbram, isbram, pb_ddr, plb_emc, plb_sdram
Timer
fit_timer, opb_timer, opb_timebase_wdt
Utility
bus_split, flipflop, reduced_logic, vector_logic

24. Processor System Size
The Processor IP Calculator is an online tool that helps you easily estimate the processor IP core size usage
Try it out!!

25. CoreConnect Features
IBM PowerPC embedded system

26. Features
Platform Generator supports the following features for OPB peripherals, and it is a subset of the OPB v2.1 features
Fully synchronous single-clock edge
32-bit address bus, 32-bit data bus
Single-cycle transfer of data between the OPB master and the OPB slave
Supports master byte enables
Supports slave timeout suppress, retry
No three-state drivers required
Note that the dynamic bus sizing feature is not supported in OPB v2.1
Dynamic bus sizing is an architectural features that allows a design to mix smaller width (like 8-bit and 16-bit) devices on a larger width bus. A master provides a master size signal, <Master>_MSize[0:1], that describes the data width of the master initiating a transaction. Slaves provide a similar signal, Sl_Mn_SSize(0:1), with the address acknowledge that describes the data width of the slave responding to the transaction. While dynamic bus sizing is a useful architectural feature, its use in FPGAs can result in inefficient implementations of PLB masters.

27. Physical Implementation
The OPB bus architecture (v2.1) allows for the addition of peripherals to the system, without changing the existing I/O on either the OPB arbiter or the other existing peripherals
The module opb_v20 in the diagram implements the OR gates defined by the OPB v2.1 specification.

28. Physical Implementation
The OPB bus architecture (v2.1) allows for the addition of peripherals to the system, without changing the existing I/O on either the OPB arbiter or the other existing peripherals
No don’t cares
The module opb_v20 in the diagram implements the OR gates defined by the OPB v2.1 specification.

29. Interface Signals Global OPB slave signals Slave signals
<Sln>_xferAck
<Sln>_errAck
<Sln>_toutSup
<Sln>_retry
<Sln>_DBus
OPB bus signals
OPB_select
OPB_RNW
OPB_BE
OPB_seqAddr
OPB_Abus
OPB_DBus
OPB
Slave
Bus
Logic
<Sln>_xferAck
<Sln>_errAck
<Sln>_toutSup
<Sln>_retry
<Sln>_DBus
OPB_select
OPB_RNW
OPB_BE
OPB_seqAddr
OPB_ABus
OPB_DBus
Slave signals
<Sln>_xferAck— transfer acknowledge
<Sln>_errAck—error acknowledge
<Sln>_toutSup—timeout suppress. Peripheral will not timeout after 16 cycles
<Sln>_retry—retry
<Sln>_Dbus—data bus
OPB bus signals
OPB_select — select
OPB_RNW — read not write
OPB_BE — byte enable
OPB_seqAddr -
OPB_Abus —address bus
OPB_Dbus —data bus

30. Create/Import Peripheral Wizard
The wizard helps you create your own peripheral and then import it into your design
The wizard will generate the necessary core description files
The user peripheral can be imported directly through the wizard by skipping the creation option
Ensure that the peripheral complies with Xilinx implementation of the IBM CoreConnect Bus Standard
The Create/Import Peripheral Wizard helps you create your own peripherals and import them into EDK compliant repositories or Xilinx Platform Studio (XPS) projects.
In the Create mode, this tool creates a number of files. Some of these files are templates that will help you implement your peripheral without requiring a detailed understanding of the bus protocols, naming conventions, or the formats of special interface files required by the EDK.
In the Import mode, this tool will help you create the interface files and directory structures that are necessary to make your peripheral visible to the various tools in the EDK. For this mode of operation, it is assumed that you have followed the naming conventions required by the EDK. Once imported, your peripheral will resemble any other module available in the
EDK peripherals library.

31. Starting the IP Wizard
The Create and Import Peripheral Wizard can be started after creating a project and using Hardware  Create or Import Peripheral … or opening an existing project or using Start  Programs  Xilinx Platform Studio 8.2i  Accessories  Create and Import Peripheral Wizard
You can start the Create and Import Peripheral Wizard after creating a new project or opening an existing project in XPS.
With a project open, start the Create and Import Peripheral Wizard at any point by selecting Hardware  Create or Import Peripheral ...

32. Software Development

33. GNU Tools Calls four different executables Preprocessor (cpp0)
Language specific c-compiler
cc1 C-programming language
cc1plus C++ language
Assembler
mb-as (MicroBlaze processor)
powerpc-eabi-as (PowerPC processor)
Linker and loader
mb-ld (MicroBlaze processor)
powerpc-eabi-ld (PowerPC processor)
1. Pre-processor: (cpp0)
This is the first pass invoked by the compiler.
The pre-processor replaces all macros with definitions, as defined in the source and header files.
2. Machine and language-specific compiler (cc1)
This compiler works on the pre-processed code, which is the output of the first stage.
a. C Compiler (cc1)
This compiler is responsible for most of the optimizations completed on the input C code and generates an assembly code.
b. C++ Compiler (cc1plus)
This compiler is responsible for most of the optimizations completed on the input C++ code and generates an assembly code.
3. Assembler (mb-as [for the MicroBlaze processor] and powerpc-eabi-as [for the PowerPC processor])
The assembly code has mnemonics in assembly language. The assembler converts these to machine language.
The assembler also resolves some of the labels generated by the compiler.
The assembler creates an object file, which is passed to the linker.
4. Linker (mb-ld [for the MicroBlaze processor] and powerpc-eabi-ld [for the PowerPC processor])
The linker links all of the object files generated by the assembler.
If libraries are provided on the command line, the linker resolves some of the undefined references in the code by linking some of the functions from the assembler.

34. Exceptions and Interrupts
Exception Code
Entry Point
Save State
Call Handler
HANDLER
Restore State
Refer to the PPC Reference Guide for more information about this process.
Return to Program
Registered Handler

35. Timer Facilities Features: Uses: Time base Fixed Interval Timer (FIT)
Programmable Interval Timer (PIT)
Watchdog timer
These timers share the same time-base clock frequency
Uses:
Time-of-day
Data logging
Peripherals requiring periodic service
Recover from faulty hardware or firmware

36. Board Support Package (BSP):
What is a BSP?
Board Support Package (BSP):
A set of software modules combined into the “libxil.a” library
Allows you to use the low-level PowerPC processor core functions
Enable, disable, and flush caches
Read/write time-base registers
Allows you to use IP peripheral-device drivers
GPIO, PCI controller, UART,…
Offers glue functionality to link code against standard libraries: Time, sleep, Files, Memory

37. PowerPC Processor Boot Files
Files: boot.S, boot0.S, crt0.S, eabi.S
Application entry point at label _boot in boot.S
_boot is single jump instruction to _boot0
_boot0 is a few instructions that do a jump to _start in crt0.S
_start
Clears .bss and .sbss sections
Sets up stack on an eight byte alignment
Initializes time-base registers to zero
Optionally, enable FPU bit in MSR
Calls main()
Calls _eabi to set R13 and R2 registers to point to .sdata and .sdata2 sections respectively
Performs user tasks
The boot.S, crt0.S, and eabi.S files contain a minimal set of code for initializing the processor and starting an application.
boot.S: Code in the boot.S consists of the boot and boot0 sections. The boot section contains only one instruction, which is labeled with _boot. During the link process, this instruction is mapped to the reset vector, and the _boot label marks the application's entry point. The boot instruction is a jump to the _boot0 label. The _boot0 label must reside within a 23-bit address space of the _boot label. It is defined in the boot0 section. The code in the boot0 section calculates the 32-bit address of the _start label and jumps to it.
crt0.S: Code in the crt0.S file starts executing at the _start label. It initializes the .sbss and .bss sections to zero, as required by the ANSI C specification, sets up the stack, initializes some processor registers, and calls the main() function. The program remains in an endless loop on return from main().
eabi.S: When an application is compiled and linked with the -msdata=eabi option, GCC inserts a call to the __eabi label at the beginning of the main() function. This is the place where register R13 must be set to point to the .sdata and .sbss data sections and register R2 must be set to point to the .sdata2 read-only data section. Code in eabi.S sets these two registers to the correct values. The _SDA_BASE_ and _SDA2_BASE_ labels are generated by the linker.

38. PowerPC Processor Memory and peripherals Special addresses
PPC405 uses 32-bit addresses
Special addresses
Every PowerPC™ system should have the boot section starting at 0xFFFFFFFC
Default linker options
Program space occupies a contiguous address space from 0xFFFF0000 to 0xFFFFFFFF
Stack size: 4 KB
Heap size: 4 KB
0x0000_0000
0xFFFF_0000
0xFFFF_FFFC
Peripherals
PLB/OPB Memory
Reset Address
After the processor completes the hardware-initialization sequence caused by a reset, the processor performs an instruction fetch from the address 0xFFFF_FFFC. This first instruction is typically an unconditional branch to the initialization code. If the instruction at this address is not a branch, instruction fetching wraps to address 0x0000_0000. The system must be designed to provide nonvolatile memory that contains the first instruction and the initialization code. Because the processor is initially in big-endian mode, initialization code must be in big-endian format. It must remain in big-endian format until the memory and processor are configured for little-endian operation.

39. Object File Sections .text Text section .rodata Read-only data section
.sdata2
.data
.sdata
.sbss
.bss
Text section
Read-only data section
Small read-only data section (less than eight bytes)
Read-write data section
Small read-write data section
Small uninitialized data section
Uninitialized data section
The .text section contains executable code. This section has the x (executable), r (read-only) and i (initialized) flags.
The .rodata section contains read-only data of a size more than 8 bytes (default). The size of the data put into this section can be changed with an mb-gcc -G option. All data in this section is accessed using absolute addresses.
The .sdata2 section contains small read-only data (size less than 8 bytes). The size of the data going into this section can be changed with an mb-gcc -G option. All data in this section is accessed with reference to the read-only small data anchor. This ensures that all data in the .sdata2 section can be accessed using a single instruction (a preceding imm instruction will never be necessary). This section has the r (read-only) and the i (initialized) flags.
The .data section contains read-write data of a size more than 8 bytes (default). The size of the data going into this section can be changed with an mb-gcc -G option. All data in this section is accessed using absolute addresses. This section has the w (read-write) and the i (initialized) flags.
The .sdata section contains small read-write data of a size less than 8 bytes (default). The size of the data going into this section can be changed with an mb-gcc -G option. All data in this section is accessed with reference to the read-write small data anchor. This ensures that all data in the .sdata section uses a single instruction (a preceding imm instruction will never be necessary). This section has the w (read-write) and the i (initialized) flags.
The .sbss section contains small uninitialized data of a size less than 8 bytes (default). The size of the data going into this section can be changed with an mb-gcc -G option. This section has the w (read-write) flag.
The .bss section contains uninitialized data of a size more than 8 bytes (default). The size of the data going into this section can be changed with an mb-gcc -G option. All data in this section is accessed using absolute addresses. The stack and the heap are also allocated to this section. This section has the w (read-write) flag.

40. Sections Example int ram_data[10] = {0,1,2,3,4,5,6,7,8,9}; /* DATA */
const int rom_data[10] = {9,8,7,6,5,4,3,2,1}; /* RODATA */
int I; /* BSS */
main(){
...
I = I + 10; /* TEXT */ }

41. Linker and Locator Flows
Executable Image
foo1.o
Merged Output Sections
.text1
0xFFFF
Code
.text
.data1
0xF000
Locate
.bss1
0xEFFF
Link
uninitialized data
.data
0xEF00
foo2.o
0xEEFF
.bss
.text2
Unused
0x2000
.data2
0x1FFF
Initialized data
.bss2
0x0000

42. Linker Script for the PowerPC Processor
Reference
Linker Script for the PowerPC Processor
Required to control how the program and data are targeted to PLB, OPB, OCM, or extended memory
Provide a linker script to the powerpc-eabi-gcc compiler
The linker script defines the layout and the start address of each of the sections
The PowerPC™ processor linker is built with default linker scripts. This script assumes a contiguous memory starting from address 0xFFFF0000. The script defines boot.o as the first file to be linked. boot.o is present in the libxil.a library, which is created by the LibGen tool. The script defines the start address as 0xFFFF0000.
If you set the start address through the linker option as -Wl, -defsym -Wl,_TEXT_START_ADDRESS=0xFFFF8000, the start address is 0xFFFF8000.
The script starts assigning addresses to different sections of the final executable: .vectors, .text, .rodata, .sdata2, .sbss2, .data, .got1, .got2, .fixup, .sdata, .sbss, .bss, .boot0, and .boot, in that order. As it assigns the addresses, the script defines the following start and end of section variables: __SDATA2_START__, __SDATA2_END__, __SBSS2_START__, __SBSS2_END__, __SDATA_START__, __SDATA_END__, __sbss_start, ___sbss_start, __sbss_end, ___sbss_end, __SDATA_START__, __SDATA_END__, __bss_start, and __bss_end.
These variables define the sectional boundaries for each of the sections. Stack and heap are allocated from the .bss section. They are defined through __stack, __heap_start, and __heap_end. However, note that the .bss section boundary does not include either stack or heap.
_end is defined after the .boot0 section definition. .boot section is fixed to start at location 0xFFFFFFFC. This section is a jump to the start of .boot0 section. The jump is defined as 24 bits. Therefore, the boot and boot0 section should not have a difference of more than 24 bits. The .boot section is at 0xFFFFFFFC because the PowerPC 405 processor, on power up, starts execution from the location 0xFFFFFFFC.

43. Linker Script Generator GUI
XPS contains a graphical Linker Script Generator
Table-based GUI allows you to define the memory space for any section
Launch from Software → Generate Linker Script, or from the Applications Tab, right-click on <project> → Generate Linker Script

44. Debugging

45. SDK Application Development Flow
Create software
App Project
Add sources
+ Edit
Compile + Link
Generate Hardware
Platform
Done?
Import ELF file,
Download to board
Debug / Profile
Platform Studio SDK
Yes
Generate Software
libraries, drivers
Platform Studio
SDK provides complementary GUI framework to XPS
What needs to be done in XPS?
- Hardware Platform generation
- Software Platform generation (incld libraries, device drivers etc)
- Software Application development
What could be done in Eclipse?
The typical procedure for using SDK to develop a software application for an XPS embedded system design is:
Using XPS, design the embedded system hardware platform and specify the software platform settings (libraries, device drivers, etc.).
Launch SDK, create a software application project, and point to the XPS project containing the embedded system platform.
Using SDK, develop and compile applications for the selected embedded system.
Using SDK, download the software executable to the target device to debug and profile your software application. (Use XPS or iMPACT tools to first download the hardware platform bitstream to the FPGA device.)
In XPS, point to the software executable created in SDK and merge it into the FPGA bitstream for production use.

46. SDK Workbench 1
C/C++ project outline displays the elements of a project with file decorators (icons) for easy identification
C/C++ editor for integrated software creation
Code outline displays elements of the software file under development with file decorators (icons) for easy identification
Problems, Console, Properties view lists output information associated with the software development flow 2 2 1 3 3 4 4

47. Debugging Using SDK Eclipse CDT XMD
powerpc-eabi-gdb
(or)
mb-gdb
JTAG / XMD protocol
Xilinx custom graphical debug interface, started off as a skin on XMD
auto-launched
gdb remote protocol
Seamless debugging – XMD-specific debug configuration; built-in XMD launcher
Integrated XMD console

48. SDK Debug Perspective 1
The stack frame for target threads that you are debugging. Each thread in your program is represented as a node in the tree
Variables, Breakpoints, and Registers views allow for viewing and real-time interaction with the view contents for more powerful debugging potential
C/C++ editor highlights the location of the execution pointer, along with allowing the setting of breakpoints 1 2 2 3 4 3 5 4
Code outline and disassembly view provide compiler level insight into the running code
Console view lists output information 5

49. Debugging in XPS vs SDK Debugging in XPS Download bitstream from XPS
Launch XMD
Provide Target Connection Options
Launch GDB (Insight GUI)
Set GDB Server connection port in GDB
Download program
Begin Debugging
Debugging in SDK
Download bitstream from XPS
Launch XMD
Provide Target Connection Options
Launch GDB (Insight GUI)
Set GDB Server connection port in GDB
Download program
Begin Debugging

50. Questions?