Você está na página 1de 234

Unified Electronic Product Development

Altium Designer FPGA, Software and Systems Development training


FPGA Design Basics
Altium Designer Training Module  FPGA Design 

Document Version 1.2, February 2008 

Software, documentation and related materials: 
Copyright © 2008 Altium Limited. 
All rights reserved. You are permitted to print this document provided that (1) the use of such is for 
personal use only and will not be copied or posted on any network computer or broadcast in any 
media, and (2) no modifications of the document is made. Unauthorized duplication, in whole or part, 
of this document by any means, mechanical or electronic, including translation into another 
language, except for brief excerpts in published reviews, is prohibited without the express written 
permission of Altium Limited. Unauthorized duplication of this work may also be prohibited by local 
statute. Violators may be subject to both criminal and civil penalties, including fines and/or 
imprisonment. 
Altium, Altium Designer, Board Insight, CAMtastic, CircuitStudio, Design Explorer, DXP, LiveDesign, 
NanoBoard, NanoTalk, Nexar, nVisage, P­CAD, Protel, SimCode, Situs, TASKING, and Topological 
Autorouting and their respective logos are trademarks or registered trademarks of Altium Limited or 
its subsidiaries. 
Microsoft, Microsoft Windows and Microsoft Access are registered trademarks of Microsoft 
Corporation. OrCAD, OrCAD Capture, OrCAD Layout and SPECCTRA are registered trademarks of 
Cadence Design Systems Inc. AutoCAD is a registered trademark of AutoDesk Inc. HP­GL is a 
registered trademark of Hewlett Packard Corporation. PostScript is a registered trademark of Adobe 
Systems, Inc. All other registered or unregistered trademarks referenced herein are the property of 
their respective owners and no trademark rights to the same are claimed. 

Module 1

ii 
Altium Designer Training Module  FPGA Design 

FPGA Design Basics 
1  FPGA Design......................................................................................................... 1­1 
1.1  Learning objectives..................................................................................... 1­1 
1.2  Topic outline............................................................................................... 1­1 
2  Introduction to FPGA Design ............................................................................... 1­2 
2.1  FPGA basics .............................................................................................. 1­2 
3  Creating an FPGA project..................................................................................... 1­3 
3.1  Overview.................................................................................................... 1­3 
3.2  A quick word about projects and design workspaces................................... 1­3 
3.3  FPGA project.............................................................................................. 1­4 
4  FPGA schematic connectivity.............................................................................. 1­5 
4.1  Overview.................................................................................................... 1­5 
4.2  Wiring the design........................................................................................ 1­5 
4.3  Including HDL source files in a schematic................................................... 1­5 
4.4  Establishing connectivity between documents............................................. 1­5 
4.5  Using buses and bus joiners....................................................................... 1­6 
5  FPGA ready schematic components ................................................................... 1­9 
5.1  Overview.................................................................................................... 1­9 
5.2  Processor cores ......................................................................................... 1­9 
5.3  Desktop NanoBoard port plugins .............................................................. 1­10 
5.4  Peripheral Components ............................................................................ 1­10 
5.5  Generic components ................................................................................ 1­10 
5.6  Vendor macro and primitive libraries......................................................... 1­10 
5.7  Exercise 1 – Create a PWM...................................................................... 1­11 
6  Targeting the design........................................................................................... 1­13 
6.1  Constraint files ......................................................................................... 1­13 
6.2  Configurations .......................................................................................... 1­14 
6.3  NanoBoard constraint files........................................................................ 1­14 
6.4  Configuration Manager ............................................................................. 1­14 
6.5  Auto Configuring an FPGA project ............................................................ 1­15 
6.6  Defining constraints manually ................................................................... 1­15 
6.7  Editing a constraint file.............................................................................. 1­16 
6.8  Exercise 2 – Configuring MyPWM............................................................. 1­17 
7  Running the design ............................................................................................ 1­19 
7.1  Overview.................................................................................................. 1­19 
7.2  Controlling the build process..................................................................... 1­19 
7.3  Understanding the build process............................................................... 1­20 
7.4  Button regions .......................................................................................... 1­20 
7.5  Accessing stage reports / outputs ............................................................. 1­21 
7.6  Build stages.............................................................................................. 1­21 
7.7  Configuring a build stage .......................................................................... 1­24 
7.8  How Altium Designer interacts with back­end vendor tools........................ 1­25 
7.9  Exercise 3 – Run MyPWM on the NanoBoard........................................... 1­25 
8  Embedded instruments ...................................................................................... 1­26 
8.1  Overview.................................................................................................. 1­26 
8.2  On­Chip debugging .................................................................................. 1­26 
8.3  CLKGEN .................................................................................................. 1­27 
8.4  CROSSPOINT_SWITCH.......................................................................... 1­27 
8.5  FRQCNT2 ................................................................................................ 1­27


Altium Designer Training Module  FPGA Design 

8.6  IOB_x....................................................................................................... 1­28 


8.7  DIGITAL_IO ............................................................................................. 1­28 
8.8  LAX_x ...................................................................................................... 1­29 
8.9  Terminal Console ..................................................................................... 1­31 
8.10  Exercise 4A – Using embedded instruments............................................. 1­31 
8.11  Where are the Instruments? ..................................................................... 1­35 
8.12  Enabling embedded instruments............................................................... 1­35 
9  Interacting with the NanoBoard ......................................................................... 1­37 
9.1  Overview.................................................................................................. 1­37 
9.2  NanoBoard communications..................................................................... 1­37 
9.3  Technical background .............................................................................. 1­38 
9.4  The NanoBoard controller......................................................................... 1­40 
9.5  FPGA I/O view.......................................................................................... 1­41 
9.6  Live cross probing .................................................................................... 1­42 
9.7  Exercise 4B – View MyPWM on the NanoBoard ....................................... 1­42 
10  Creating a core component................................................................................ 1­43 
10.1  Core project.............................................................................................. 1­43 
10.2  Creating a core component from an FPGA project .................................... 1­43 
10.3  A word about EDIF ................................................................................... 1­44 
10.4  Setting up the core project ........................................................................ 1­44 
10.5  Constrain / configure ................................................................................ 1­45 
10.6  Creating a new constraint file.................................................................... 1­46 
10.7  Creating a configuration............................................................................ 1­47 
10.8  Synthesize ............................................................................................... 1­48 
10.9  Publish ..................................................................................................... 1­49 
10.10  Creating a core schematic symbol ............................................................ 1­49 
10.11  Using a core component........................................................................... 1­51 
10.12  Exercise 5 – Create a core component from MyPWM ............................... 1­52 
11  FPGA design simulation..................................................................................... 1­53 
11.1  Creating a testbench ................................................................................ 1­53 
11.2  Assigning the Testbench Document.......................................................... 1­53 
11.3  Initiating a simulation session ................................................................... 1­54 
11.4  Project compile order................................................................................ 1­54 
11.5  Setting up the simulation display............................................................... 1­55 
11.6  Running and debugging a simulation ........................................................ 1­56 
11.7  Exercise 6 – Create a testbench and simulate MyPWM ............................ 1­58 
12  Review................................................................................................................. 1­59

ii 
Altium Designer Training Module  FPGA Design 

1  FPGA Design 
The primary objective of this day of training is to make participants proficient in the process of 
developing, downloading and running an FPGA design on the Desktop NanoBoard.  We will go 
through the FPGA design framework and demonstrate just how simple FPGA design is with Altium 
Designer. 

1.1  Learning objectives
· To be competent in developing FPGA designs using standard FPGA­based libraries and the 
schematic capture environment
· To understand and be able to make use of the FPGA build process
· To be familiar with the peripheral capabilities of the Desktop NanoBoard and know how to 
incorporate their use in custom FPGA designs.
· To appreciate the different communication mechanisms used by the software to control and probe 
a running FPGA design.
· To be competent with the use of virtual instruments in an FPGA design. 

1.2  Topic outline 
Core Topics

FPGA  FPGA 
FPGA Build 
Project  Schematic 
Process 
Creation  Extensions 
FPGA design 
built and 
loaded onto 
NanoBoard 
NanoBoard  FPGA 
Concepts  Instruments 

Advanced Topics (Time Permitting) 

FPGA Core  Digital 
Components  Simulation 

Figure 1. Topic Outline for Part I – FPGA Design Basics. 

1 ­ 1 
Altium Designer Training Module  FPGA Design 

2  Introduction to FPGA Design 
2.1  FPGA basics 
FPGA: Field Programmable Gate Array.  Conceptually it can be considered as an array of 
Configurable Logic Blocks (CLBs) that can be connected together through a vast interconnection 
matrix to form complex digital circuits. 

Figure 2. Exploded view of a typical FPGA 

FPGAs have traditionally found use in high­speed custom digital applications where designs tend to 
be more constrained by performance rather than cost.  The explosion of integration and reduction in 
price has led to the more recent widespread use of FPGAs in common embedded applications. 
FPGAs, along with their non­volatile cousins CPLDs (Complex Programmable Logic Devices), are 
emerging as the next digital revolution that will bring about change in much the same way that 
microprocessors did. 
With current high­end devices exceeding 2000 pins and topping billions of transistors, the complexity 
of these devices is such that it would be impossible to program them without the assistance of high­ 
level design tools.  Xilinx, Altera, Actel, and Lattice all offer high­end EDA tool suites designed 
specifically to support their own devices however they also offer free versions aimed at supporting 
the bulk of FPGA development.  These vendors understand the importance of tool availability to 
increased silicon sales and they all seem committed to supporting a free version of their tools for the 
foreseeable future. 
Through the use of EDA tools, developers can design their custom digital circuits using either 
schematic based techniques, VHDL, Verilog or any combination of these methods.  Prior to the 
Altium Designer system, vendor independent FPGA development tools were extremely expensive. 
Furthermore they were only useful for circuits that resided within the FPGA device.  Once the design 
was extended to include a PCB and ancillary circuits, a separate EDA tool was needed.  Altium 
Designer has changed all of this by being the first EDA tool capable of offering complete schematic 
to PCB tool integration along with multi­vendor FPGA support. 
Altium made the logical extrapolation of trends in the FPGA world and recognized that FPGAs are 
quickly becoming a staple in modern designs.  By making available a range of processor cores that 
can be downloaded onto an FPGA device and bundling them with a complete suite of embedded 
software development tools, Altium Designer represents a unified PCB and embedded systems 
development tool.

1 ­ 2 
Altium Designer Training Module  FPGA Design 

3  Creating an FPGA project 
3.1  Overview 
All components that will be combined together into a single FPGA design must be encapsulated 
within an FPGA Project. 
The term “Project” refers to a group of documents that combine together to form a single target. 
Care must be exercised when creating a project to ensure that the correct project type is selected for 
the desired target. 

3.2  A quick word about projects and design workspaces 
To the uninitiated, Altium Designer projects may appear a little 
confusing; especially when projects contain other projects. 
The important thing to remember is that each project can only 
have one output.  If you have a design that requires several 
PCBs then you will need a separate PCB project for each 
PCB.  If you have a design that uses several FPGAs then you 
will also need a separate FPGA project for each FPGA used 
on the final design. 
Projects that are related together in some way can be grouped 
together using a type of ‘super project’ called a Design 
Workspace.  Design Workspaces are simply a convenient 
way of packaging one or more projects together so that all 
projects from a single design can be opened together. 
Altium Designer supports a fully hierarchical design approach. 
As such it is possible for some projects to contain other 
projects within them.  Figure 3 shows a structural view of the 
Spirit Level design that is distributed as an example in the 
Altium Designer installation.  From this view we can observe 
the hierarchy of the different projects involved.  The top­level 
project is a PCB project called SL1 Xilinx Spartan­IIE 
PQ208 Rev1.01  and has the filename extension PRJFPG.  Figure 3. An example of project hierarchy.
Within this PCB project is an instance of an FPGA Project 
FPGA_51_Spirit_Level.PrjFpg.  Running on the FPGA is a 
softcore processor 8051.  The program or software that this embedded softcore executes is 
contained within another project called SpiritLevel.PrjEmb. 

The hierarchy of projects is given below. 

PRJPCB  PCB Project  Output is a single PCB 

PRJFPG  FPGA Project  Output is a single FPGA 

Source code for a program that will execute 
PRJEMB  Embedded Project  on a single softcore 

Figure 4. Possible Project Hierarchy for a design containing multiple projects 

A PCB Project may contain one or more FPGA projects but never the other way around.  If you think 
about it you will recognize that it is quite intuitive; a PCB contains FPGAs whereas an FPGA can’t 
contain a PCB.  Similarly, an FPGA could contain one or more custom FPGA cores or 
microprocessor softcores.  A linked Embedded Project will define the software that executes on each 
of the softcores. 

1 ­ 3 
Altium Designer Training Module  FPGA Design 

3.3  FPGA project 
An FPGA project should be used when the target is a single FPGA.  The output of an FPGA project 
will be a configuration bit file that can be used to program an FPGA. 

The simplest way to create a project is from the File menu (File » New » Project). 

Figure 5. Creating a new FPGA project

1 ­ 4 
Altium Designer Training Module  FPGA Design 

4  FPGA schematic connectivity 
4.1  Overview 
Schematic documents used in FPGA designs are converted to either VHDL or Verilog in the process 
of being compiled into the design.  This process is totally transparent to the user and does not 
require the user to know anything specific about either of these two Hardware Description 
Languages (HDLs).  This conversion to HDLs does place some requirements onto the schematic 
document however that must be considered to ensure that the conversion process goes smoothly 
and that the resultant HDL source file is valid. 
In this section we will discuss some of the extensions that have been added to the schematic 
environment for the purposes of servicing FPGA designs. 

4.2  Wiring the design 
Connectivity between the component pins is created by physical connectivity, or logical connectivity. 
Placing wires that connect component pins to each other creates physical connectivity. Matching net 
identifiers such as net labels, power ports, ports and sheet entries creates logical connectivity. When 
the design is compiled the connectivity is established, according to the net identifier scope defined 
for the project. 
Note that while the environment supports compiling projects using either a flat or hierarchical 
connective structure, FPGA projects must be hierarchical. 

4.3  Including HDL source files in a schematic 

Figure 6. Linking schematic sheet symbols to lower level documents 

VHDL or Verilog sub­documents are referenced in the same way as schematic sub­sheets, by 
specifying the sub­document filename in the sheet symbol that represents it. The connectivity is from 
the sheet symbol to an entity declaration in the VHDL file or the Verilog module. To reference an 
entity with a name that is different from the source HDL filename, include the VHDLEntity or 
VerilogModule parameter in the sheet symbol whose value is the name of the Entity / Module 
declared in the source file (as shown above). 

4.4  Establishing connectivity between documents 
Hierarchical net and bus connectivity between documents obeys the standard hierarchical project 
connection behavior, where ports on the sub­document connect to sheet entries of the same name in 
the sheet symbol that represents that document, as shown below.

1 ­ 5 
Altium Designer Training Module  FPGA Design 

Figure 7. Connectivity between sheet symbols and lower level documents 

4.5  Using buses and bus joiners 
Typically there are a large number 
of related nets in a digital design.  U8  IB[3..0] 
GND 
Buses can play an important role 
in managing these nets, and help  PORTA[7..0]  O[7..0]  IA[3..0] 
KEY[3..0] 
J4B2_8B 
present the design in a more 
readable form. 
Buses can be re­ordered,  PORTB[7..0]  O[7..0]  U9  I0 
renamed, split, and merged. To  LCD_BUSY 
I1 
VALIDKEY 
manage the mapping of nets in  I2 
buses, there is a special class of  I3 
I4 
component, known as a bus  I5 
joiner. Bus joiners can be placed  I6 
from the FPGA  I7 
GND 
Generic.IntLib library (bus  J8S_8B 
joiner names all start with the  Figure 8. Examples of using bus joiners
letter J). Figure 8 shows examples 
of using bus joiners. There are 
also many examples of using bus joiners in the example designs in the software. 
Note that apart from the JB­type joiner, all bus joiner pins have an IO direction – use the correct 
joiner to maintain the IO flow. Pin IO can be displayed on sheet if you enable the Pin Direction 
option in the Schematic Preferences dialog. 
The use of bus joiners in FPGA designs is a significant departure from how bus connectivity is 
established on other schematic documents however the benefits of bus joiners soon become clear. 
Nets extracted from a bus joiner need not be related in any way – ie. have the same name and 
differing only by number (Data[0], Data[1], Data[2], … etc).  The bus joiner example above shows 
how a single bus can be used to route a number of LCD and Keypad signals together, even allowing 
the joining of other busses into a single bus of a larger width. 

4.5.1  Bus joiner naming convention 
Bus joiners follow a standardized naming convention so that they can be easily found within the 
FPGA Generic.IntLib library. 
J<width><B/S>[Multiples]_<width><[B/S]>[Multiples] 
For example: 
J8S_8B: describes a bus joiner that routes 8 single wires to a single, 8­bit bus. 
J8B_8S: describes a bus joiner that routes a single, 8­bit bus into 8 single wires. 
J8B_4B2: describes a bus joiner that routes a single 8­bit bus into two 4­bit busses, 
J4B4_16B: describes a bus joiner that routes four, 4­bit busses into a single 16­bit bus. 

1 ­ 6 
Altium Designer Training Module  FPGA Design 

4.5.2  Bus joiner splitting / merging behaviour 
The basic rule is that bus joiners separate/merge the bits (or bus slice) 
from least significant bit (or slice) down to most significant bit (or slice). 
For example, in Figure 9, U17 splits the incoming 8­bit bus on pin I[7..0] 
into two 4­bit bus slices, OA[3..0] and OB[3..0]. Obeying the least to most 
mapping at the slice level, the lower four bits of the input bus map to 
OA[3..0], and the upper four bits map to OB[3..0]. Following this through to 
the bit level, I0 will connect to OA0, and I7 will connect to OB3. 
The joiner U27 merges the four incoming 4­bit slices into a 16­bit bus. With 
this joiner IA0 connects to O0, and ID3 connects to O15. 

4.5.3  Matching buses of different widths using the 
JB­type bus joiner 
Figure 9. Bus joiners 
The JB­type bus joiner allows you to match nets in buses of different  merge and split buses
widths. It does this via 2 component parameters, IndexA and IndexB that 
map from one bus through to the other bus. These indices must be defined when you use a JB 
joiner. 

Figure 10. Join buses of different widths, and control the net­to­net mapping 

Read the flow of nets through a JB­type bus joiner by matching from the nets in the attached bus, to 
the first index on the bus joiner, to the second index in the bus joiner, to the nets defined in the 
second bus net label. 
Left Bus ↔ IndexA ↔ IndexB ↔ Right Bus 
The rules for matching nets at each of the ↔ points are as follows: 

Figure 11. An example of using the JB bus joiner to achieve sub­set mapping

· If both bus ranges are descending, match by same bus index (one range must lie within the other 
for valid connections). In Figure 11 the matching is: 
ADDR9 ↔ IndexA9 ↔ IndexB9 ↔ ROMADDR9, thru to 
ADDR0 ↔ IndexA0 ↔ IndexB0 ↔ ROMADDR0 

(In this example ROMADDR10 thru ROMADDR13 will be unconnected) 

Figure 12. Using of a bus joiner for offset mapping

· In Figure 12 the matching is: 
INPUTS15  ↔ IndexA15 ↔ IndexB31 ↔ PORTB31, thru to 
INPUTS0  ↔ IndexA0  ↔ IndexB0  ↔ PORTB16 

1 ­ 7 
Altium Designer Training Module  FPGA Design 

Figure 13. Using a bus joiner for range inversion

· If one bus range is descending and another is ascending, the indices are matched from left to 
right. In Figure 13 the matching is: 
INPUTS0  ↔ IndexA15 ↔ IndexB31 ↔ PORTB31, thru to 
INPUTS15 ↔ IndexA0  ↔ IndexB16 ↔ PORTB16 

Figure 14. Another example of using a bus joiner for range inversion

· In Figure 14 the matching is: 
INPUTS15  ↔ IndexA15 ↔ IndexB31 ↔ PORTB0, thru to 
INPUTS0  ↔ IndexA0  ↔ IndexB16  ↔ PORTB15

1 ­ 8 
Altium Designer Training Module  FPGA Design 

5  FPGA ready schematic components 
5.1  Overview 
A wide variety of FPGA­ready schematic 
components are included with the system, ranging 
from processors, to peripheral components, down 
to generic logic. Placing and wiring these 
schematic components, or writing VHDL, captures 
the hardware design. The FPGA­ready schematic 
components are like traditional PCB­ready 
components, except instead of the symbol being 
linked to a PCB footprint each is linked to a pre­ 
synthesized EDIF model. 
As well as components that you use to implement 
your design, the available FPGA libraries include 
components for the virtual instruments, and the 
components that are mounted on the NanoBoard 
and are accessible via the pins on the FPGA. 
Help for all FPGA­ready components can be 
accessed by pressing the F1 key whilst the 
component is selected in the library list. 

5.2  Processor cores 
Softcore processors can be placed from the 
\Program Files\Altium Designer 
6\Library\Fpga\FPGA Processors.IntLib 
library. At the time of release of this manual, the 
following processors and related embedded 
software tools are supported:
· TSK165 – Microchip 165x family instruction set 
compatible MCU
· TSK51/52 – 8051 instruction set compatible 
MCU
· TSK80 – Z80 instruction set compatible MCU
· PPC405A – Embedded Power PC Core 
available on some Virtex FPGAs
· TSK3000 – 32­bit RISC processor 
There is also full embedded tool support for:
· Actel CoreMP7 softcore, which requires the 
appropriate Actel device and license to use
· Altera Nios II softcore, which requires the 
appropriate Altera device and license to use
Figure 15. The libraries panel
· Xilinx MicroBlaze soft core, which requires the 
appropriate Xilinx device and license to use
· Xilinx Virtex­2 Pro based PowerPC 405
· AMCC PowerPC 405 discrete processor family
· ARM7, ARM9, ARM9E & ARM10E families, supported in the Sharp BlueStreak (ARM20T) 
discrete processor family
· LPC2100, LPC2200, LPC2300 & LPC2800 ARM7­based discrete processors from NXP 

1 ­ 9 
Altium Designer Training Module  FPGA Design 

5.3  Desktop NanoBoard port plugins 
Hardware resources on the Desktop NanoBoard can be accessed via the use of components from 
the \Program Files\Altium Designer 6\Library\Fpga\FPGA NB2DSK01 Port­ 
Plugin.IntLib library. 

5.4  Peripheral Components 
Many of the hardware resources present on the NanoBoard come with peripheral modules that can 
be included in the FPGA design to ease interfacing to the external port. 
Peripherals can be placed from the \Program Files\Altium Designer 
6\Library\Fpga\FPGA Peripherals.IntLib library. 

5.5  Generic components 
Generic components can be placed from the library 
\Program Files\Altium Designer 
6\Library\Fpga\FPGA Generic.IntLib. This 
library is included to implement the interface logic 
in your design. It includes pin­wide and bus­wide 
versions for many components, simplifying the 
wiring complexity when working with buses. As well 
as a broad range of logic functions, the generic 
library also includes pullup and pulldown 
components as well as a range of bus joiners, used 
to manage the merging, splitting and renaming of 
buses. 
For a definition of the naming convention used in 
the generic library and a complete listing of 
available devices, refer to the document: CR0118 
FPGA Generic Library Guide.pdf. 
Wild card characters can be used to filter when 
searching the component library. 

5.6  Vendor macro and 
primitive libraries 
If vendor independence is not required, there are 
also complete primitive and macro libraries for the 
currently supported vendors/device families. These 
libraries can be found in the respective Actel, 
Altera, Lattice and Xilinx sub­folders in \Program 
Files\Altium Designer 6\Library\. The 
macro and primitive library names end with the 
string *FPGA.IntLib. Note that some vendors  Figure 16. Using wildcards to quickly find a specific 
component in the Generic Library
require you to use primitive and macro libraries that 
match the target device. Designs that include 
vendor components cannot be re­targeted to 
another vendor’s device. 

1 ­ 10 
Altium Designer Training Module  FPGA Design 

5.7  Exercise 1 – Create a PWM 
In this exercise we will create our first FPGA design.  In order to complete this task you will need to 
use the following components from their respective libraries: 

Component  Library  Name in Library 


FPGA NB2DSK01 Port­Plugin.IntLib  CLOCK_BOARD 
CLK_BRD 

FPGA NB2DSK01 Port­Plugin.IntLib  TEST_BUTTON 
TEST_BUTTON 

ON 

SW[7..0]  FPGA NB2DSK01 Port­Plugin.IntLib  DIPSWITCH 


1  2  3  4  5  6  7  8 

LEDS[7..0]  FPGA NB2DSK01 Port­Plugin.IntLib  LED 

U1  FPGA Generic.IntLib  CB8CEB 


CB8CEB 
Q[7..0] 

CE CEO 
C  TC 
CLR 

U2  FPGA Generic.IntLib  INV 

INV 

U3  FPGA Generic.IntLib  COMPM8B 


A[7..0]  GT 
B[7..0]  LT 
COMPM8B 

U4 
FPGA Generic.IntLib  J8S_8B
I0  O[7..0] 
I1 
I2 
I3 
I4 
I5 
I6 
I7 
J8S_8B 

1.  Open a new FPGA Project.  Save it as MyPWM.PrjFpg 
2.  Add a new schematic to your project and save it as MyPWM.SchDoc 
3.  Place and wire the components to create the Pulse Width Modulator 
4.  Using components from the two libraries FPGA Generic.IntLib and FPGA NanoBoard 
Port Plugin.IntLib, place and wire the schematic shown in Figure 17. 

1 ­ 11 
Altium Designer Training Module  FPGA Design 

U1 
CB8CEB 
Q[7..0] 
VCC 
CE CEO 
CLK_BRD  C  TC 
CLR 
U2  U3 
U4 
I0  O[7..0] 
TEST_BUTTON  A[7..0]  GT  LEDS[7..0] 
I1 
B[7..0]  LT 
INV  I2 
COMPM8B  I3 
I4 
ON 
I5 
SW[7..0] 
1  2  3  4  5  6  7  8  I6 
I7 
J8S_8B 

GND

Figure 17. Save your work – we will continue with this schematic soon 

1 ­ 12 
Altium Designer Training Module  FPGA Design 

6  Targeting the design 
The schematic that we have just created contains all of the connectivity that must occur internally on 
our FPGA device but we still need some further information to map the ports on the FPGA schematic 
to physical pins on an actual FPGA device.  This process is called targeting our design. 

6.1  Constraint files 
Rather than storing device and implementation specific data such as pin allocations and electrical 
properties in the source HDL or schematic documents, this information is stored in separate files – 
called Constraint files. This decoupling of the logical definition of an FPGA design from its physical 
implementation allows for quick and easy re­targeting of a single design to multiple devices and PCB 
layouts. 
Below we see a conceptual representation of an FPGA design sitting inside an FPGA device.  The 
red lines indicate the port­to­pin mappings that would be handled by the constraint file. 

Figure 18. Conceptual view showing the linkage of ports on an FPGA schematic routed to physical device pins.

1 ­ 13 
Altium Designer Training Module  FPGA Design 

6.2  Configurations 
A Configuration is a set of one or more constraint files that must be used to target a design for a 
specific output.  The migration of a design from prototype to production will often involve several 
PCB iterations and possibly even different FPGA devices.  In this case, a separate configuration 
would be used to bring together constraint file information from each design iteration.  Each new 
configuration (and its associated constraint file(s) is stored with the project and can be recalled at 
any time. 
Because configurations can contain multiple constraint files, it can sometimes be helpful to split 
constraint information across multiple constraint files.  Usually one would separate the constraint files 
according to the class of information they contain: 

6.2.1  Device and board constraint information: 
The specific FPGA device must be identified and ports defined in the top level FPGA design must be 
mapped to specific pin numbers. 

6.2.2  Device resource constraint information: 
In some designs it may be advantageous to make use of vendor specific resources that are unique 
to a given FPGA device.  Some examples are hardware multiplication units, clock multipliers and 
memory resources. 

6.2.3  Project or design constraint information: 
This would include requirements which are associated with the logic of the design, as well as 
constrains on its timing.  For example, specifying that a particular logical port must be allocated to 
global clock net, and must be able to run at a certain speed. 

6.3  NanoBoard constraint files 
Constraint files for use with the NanoBoard daughter / peripheral board modules can be found in the 
\Program Files\Altium Designer 6\Library\Fpga directory.  To protect these system 
files from inadvertent modification, it is advisable to make this directory ‘read only’. 

6.4  Configuration Manager 
The grouping of multiple constraints into a single configuration is managed via the Configuration 
Manager; accessible by right­clicking the FPGA project in the Projects panel and selecting 
Configuration Manager from the menu. 

Figure 19. Configuration Manager showing multiple configurations and constraint files. 

Figure 19 shows the Configuration Manager dialog for a project that contains multiple configurations 
and constraint files.  The Constraint files are listed in the left column and can be included in a 
Configuration (listed as the headings in the four right columns) by placing a tick at the row/column 
intersection point.  Although this example only shows one constraint file being used in each of the 
configurations, there is no reason why a constraint file can’t be used by more than one configuration 
nor is there any reason why a configuration can’t make use of multiple constraint files.

1 ­ 14 
Altium Designer Training Module  FPGA Design 

6.5  Auto Configuring an FPGA project 
Configuring a design for use 
with the Desktop NanoBoard 
has been almost completely 
automated with the introduction 
of the Auto Configuration option 
in Altium Designer.  From the 
Devices View located under 
View»Devices View or 
alternatively accessed from the 
icon in the toolbar, simply 
right­click the image of the 
Desktop NanoBoard and select 
the option Configure FPGA 
Project»<Project Name>. 
Figure 20. Auto configuring an FPGA 

This will automatically configure the FPGA Project to include the constraint files required to target the 
hardware on the Desktop Nanoboard and will launch the Configuration Manager dialog for the 
current FPGA project. 

Figure 21. Auto configuration displayed in the configuration manager 

6.6  Defining constraints manually 
Often it is necessary to manually create design constraints.  These include constraints for such 
physical attributes as the frequency of a system clock, or the association of signals to specific device 
pins (such as one might expect to find when targeting a design for a user board).  To create a user 
constraint file, right click the FPGA project and select Add New to Project»Constraint File.  This 
will create a new blank constraint file and add it to the project. 

Figure 22. New blank constraint file

1 ­ 15 
Altium Designer Training Module  FPGA Design 

6.7  Editing a constraint file 
Constraint file additions / modifications can be made by manually editing the constraint file or by 
using the Design » Add/Modify Constraint menu. 

Figure 23. Add/Modify Constraint… menu options 

6.7.1  Specifying port constraints 
Use the Add/Modify Constraint » Port to 
apply a constraint to a port in the FPGA 
project. 

Figure 24. Add/Modify Port Constraint dialog box. 

Selecting OK from the dialog box in Figure 24 will cause the following constraint to be added to the 
constraint file: 
Record=Constraint | TargetKind=Port | TargetId=CLK_BRD | FPGA_CLOCK_PIN=True 
This constraint will ensure that the Vendor FPGA tools route the CLK_BRD port to a specialized 
clock pin on the target device. 
Alternatively, the FPGA_PINNUM 
constraint can be specified to lock the port 
to a specific pin on the target device. 

Figure 25. Add/Modify Port Constraint dialog box. 

Selecting OK from the dialog box in Figure 25 will add the constraint FPGA_PINNUM=P185 to the 
CLK_BRD port constraint. 
A complete list of the supported constraints and their syntax can be found in the document TR0130 
Constraint File Reference.PDF located under the Knowledge Center or from the Altium website.

1 ­ 16 
Altium Designer Training Module  FPGA Design 

6.8  Exercise 2 – Configuring MyPWM 
1.  Switch to the Devices View under View»Devices Views or by hitting the  button in the 
toolbar at the top of the screen. 
2.  Right Click the image of the 
Desktop Nanoboard at the top 
of the window and select 
Configure FPGA 
Project»MyPWM.PrjFpg as 
seen in Figure 26. 
Because we are targeting our 
design for the Desktop 
NanoBoard, we will be using 
existing constraint files 
located in the Altium Designer 
6\Library\FPGA directory. 
When we elect to auto 
configure as we have in this 
fashion, Altium Designer will  Figure 26. Configuring the FPGA Project Automatically
retrieve information about the 
daughterboard and various peripheral boards that we have plugged in to the Desktop 
NanoBoard and add constraint files as required. 
3.  After launching the Configure FPGA Project command, the Configuration Manager For 
MyPWM.PRJFPG dialog should come up and show a listing of all of the constraints files that 
have been automatically included under this new configuration. 

Figure 27. Configuration Manager with constraint files added by the Configure Fpga Project command. 

Click OK to close this dialog and the Hard JTAG Chain should now appear in the main 
window.  You may notice that a new Settings folder has been added to the project.  In this 
folder you will find a Constraint Files folder with all of the newly added constraint files. 
Several of the files will have a ‘shortcut’  symbol. 

Figure 28. Build flow after auto configuring the FPGA design. 

1 ­ 17 
Altium Designer Training Module  FPGA Design 

4.  The auto­configuration process deals with the mapping of ports defined on the top­level FPGA 
schematic document and their target FPGA pins.  There are, however, additional constraints 
(such as the clock frequency) that are important for the design but which can not be handled 
automatically. In order to capture this information, it is best to create another constraint file that 
is reserved for this information and add it to the configuration.  Right click the FPGA project 
and select Add New to Project»Constraint File to add a new, blank constraint file. 
5.  Save the new constraint file with the name MyConstraint.constraint 
6.  Select Design>>Add/Modify Constraint… >> Port … . 
7.  In the Add/Modify Port Constraint dialog set the Target to CLK_BRD 
8.  Set the Constraint Kind to FPGA_CLOCK_FREQUENCY 
9.  Set the Constraint Value to 50MHz. 
10.  Click OK to close the Add/Modify Port Constraint dialog. 
11.  Observe that a new constraint record has been added to MyConstraints.Constraint. 

12.  Save your work. 
13.  Return to the Configuration Manager and add MyConstraint.Constraint to the existing 
configuration. 
14.  Save your project.

1 ­ 18 
Altium Designer Training Module  FPGA Design 

7  Running the design 
Having just configured our design for the NanoBoard the next step is to build and run the design on 
the NanoBoard. 

7.1  Overview 
Before an FPGA design can be downloaded onto its target hardware, it must first undergo a multi­ 
stage build process.  This process is akin to the compilation process that software undergoes in 
order to create a self­contained program. In this section we will discuss the various steps necessary 
to build an FPGA design to the point where it is ready to be downloaded onto the target device. 

7.2  Controlling the build process 
The process of converting a schematic or VHDL description of a digital circuit into a bit file that can 
be downloaded onto an FPGA is quite complex.  Fortunately, Altium Designer goes to great lengths 
to ensure that navigation through this process is as easy as possible.  As a vendor independent 
FPGA development tool, Altium Designer provides a transparent interface to the vendor specific 
back end tools.  Currently Altium Designer supports interaction with Actel Designer (Actel), Quartus II 
(Altera), ispLEVER (Lattice), and ISE (Xilinx) to perform FPGA processing.  This is all handled 
seamlessly through the Devices View (View » Devices).  The Devices View provides the central 
location to control the process of taking the design from the capture state through to implementing it 
in an FPGA. 

Figure 29. Devices view of an FPGA design that is yet to be processed. 

When run in the Live mode, Altium Designer is intelligent enough to detect which daughter board 
device is present on the Desktop NanoBoard.  In the above instance, it has detected that the 
Spartan3 daughter board is installed.  With this information, it then searches the current project’s 
configuration list to see if any configurations match this device.  If more than one configuration is 
found, the drop down list below the device icon will be populated with a list of valid configurations.  If 
no configuration can be found, the list will display the following: 

Figure 30. This message indicates that the project is not configured to target the available FPGA. 

Assuming a valid configuration can be found, the simplest way to build and download a design onto 
the NanoBoard is to left­click on the Program FPGA button.  This will invoke the appropriate build 
processes that need to be run.  In the above example where no previous builds have taken place, all 
processes will need to be run.  In other situations where a project has just been modified, it may be 
necessary for only a subset of the build processes to run.

1 ­ 19 
Altium Designer Training Module  FPGA Design 

7.3  Understanding the build process 

Figure 31. Navigating through the Build Process flow. 

Building an FPGA project requires processing through a number of stages.  Navigation through the 
build process is accomplished via the four steps circled in Figure 31.  The function of each stage will 
be explained shortly. 

7.4  Button regions 
Each of the main buttons displayed in the build flow have several regions that provide information or 
control over the individual build stage. 

7.4.1  Status LED 

The colored indicator tells you the status of that particular step in the overall build flow. 
Grey  ­  Not Available ­ The step or stage cannot be run. 

Red  ­  Missing ­ The step or stage has not been previously run. 

Yellow  ­  Out of Date ­ A source file has changed and the step or stage must be run again in order 
to obtain up to date file(s). 

Blue  ­  Running ­ The step or stage is currently being executed. 

Orange  ­  Cancelled – The step or stage has been halted by user intervention. 

Magenta  ­  Failed ­ An error has occurred while running the current step of the stage. 

Green  ­  Up to Date – The step or stage has been run and the generated file(s) are up to date. 

7.4.2  Run all 

Clicking on the ‘arrow’ icon will force the current stage and all prior stages to run regardless of 
whether they have run to completion previously.  Selecting this icon will force a totally clean build 
even if the design has been partially built. 

7.4.3  Run 

Selecting the ‘label’ region will run the current stage and any previous dependant stages that are not 
up to date.  This is the quickest way to build a design as it only builds those portions of the design 
that actually require it.

1 ­ 20 
Altium Designer Training Module  FPGA Design 

7.4.4  Show sub­stages 

Selecting the ‘down arrow’ will expose a drop down list of the various sub­stages for the current build 
stage.  The status of the various sub­stages is indicated by the color of the status ‘LED’.  Where a 
sub­stage has failed, the associated report file can be examined to help determine the cause of the 
failure. 

Figure 32. Sub­stages available under the main build stage. 

7.5  Accessing stage reports / outputs 
All generated output files are stored in a folder with the same name as the configuration used for the 
associated project. This folder is located at the output path defined in the Options tab of the Options 
for Project dialog (Project » Project Options).  In general only files that are created as part of the 
build process should be located here.  This ensures that projects can be compacted by deleting this 
directory without fear of loss of important information. 
Where a report is available upon running a stage step, clicking on the associated  icon can access 
it.  Use this feature to access detailed information relating to why a specific stage may have failed to 
build. 

7.6  Build stages 
We will now explain the different stages in the build process. 

7.6.1  Compile 

Figure 33. Compile stage of the process flow. 
This stage of the process flow is used to perform a compile of the source documents in the 
associated FPGA project. If the design includes any microprocessor cores, the associated 
embedded projects are also compiled – producing a Hex file in each case. 
This stage can be run with the Devices view configured in either Live or Not Live mode. 
The compile process is identical to that performed from the associated Project menu. Running this 
stage can verify that the captured source is free of electrical, drafting and coding errors. 
Note: The source FPGA (and embedded) project(s) must be compiled – either from the Projects 
panel or by running the Compile stage in the Devices view – in order to see Nexus­enabled device 
entries in the Soft Devices region of the Devices view.

1 ­ 21 
Altium Designer Training Module  FPGA Design 

7.6.2  Synthesize 

Figure 34. Synthesize stage of the process flow. 
This stage of the process flow is used to synthesize the compiled FPGA project, as well as any other 
components that need to be generated and synthesized to specific device architectures. The vendor 
place and route tools subsequently use the synthesis files generated, during the build stage of the 
flow. Running this stage will determine whether the design is synthesizable or not. 
This stage can be run with the Devices view configured in either Live or Not Live mode. 
The actual steps involved in providing a top­level EDIF netlist and satellite synthesis model files for 
use by the next stage in the process flow can be summarized as follows:
· The cores for any design/device specific blocks used in the FPGA design will be auto­generated 
and synthesized (e.g. a block of RAM wired to an OCD­version micro controller for use as 
external Program memory space). These synthesized models will contain compiled information 
from the embedded project (Hex file).
· The main FPGA design is then synthesized. An intermediate VHDL or Verilog file will be 
generated for each schematic sheet in the design and a top­level EDIF netlist will be created 
using these and any additional HDL source files.
· For the particular physical device chosen, synthesized model files associated with components in 
the design will be searched for and copied to the relevant output folder. Both System and User 
presynthesized models are supported.
· The top­level folder for System presynthesized models is the \Program Files\Altium 
Designer 6\Library\Edif folder, which is sub­divided by Vendor and then further by device 
family.
· The top­level folder for user presynthesized models is defined in the Synthesis page of the 
FPGA Preferences dialog, accessed under the Tools menu.
· The following list summarizes the order (top to bottom = first to last) in which folders are searched 
when looking for a synthesized model associated with a component in the design: 
FPGA project folder 
User models top folder\Vendor folder\Family folder 
User models top folder\Vendor folder 
User models top folder 
System models top folder (Edif)\Vendor Folder\Family folder 
System models top folder (Edif)\Vendor folder 
System models top folder (Edif). 

7.6.3  Build 

Figure 35. Build stage of the process flow for Xilinx devices. 

This stage of the process flow is used to run the vendor place and route tools. This stage can be run 
with the Devices view configured in either live or not live mode.

1 ­ 22 
Altium Designer Training Module  FPGA Design 

Running the tools at this stage can verify if a design will indeed fit inside the chosen physical device. 
You may also wish to run the Vendor tools if you want to obtain pin assignments for importing back 
into the relevant constraint file. 
The end result of running this stage is the generation of an FPGA programming file that will 
ultimately be used to program the physical device with the design. There are essentially five main 
stages to the build process:
· Translate Design – uses the top­level EDIF netlist and synthesized model files, obtained from 
the synthesis stage of the process flow, to create a file in Native Generic Database (NGD) format 
– i.e. vendor tool project file
· Map Design to FPGA – maps the design to FPGA primitives
· Place and Route ­ takes the low­level description of the design (from the mapping stage) and 
works out how to place the required logic inside the FPGA. Once arranged, the required 
interconnections are routed
· Timing Analysis – performs a timing analysis of the design, in accordance with any timing 
constraints that have been defined. If there are no specified constraints, default enumeration will 
be used
· Make Bit File – generates the programming file that is required for downloading the design to the 
physical device. 
When targeting a Xilinx device, an additional stage is available – Make PROM File. This stage is 
used when you want to generate a configuration file for subsequent download to a Xilinx 
configuration device on a Production board. 
After the Build stage has completed, the Results Summary dialog will appear (Figure 36). This 
dialog provides summary information with respect to resource usage within the target device. 
Information can be copied and printed from the dialog. The dialog can be disabled from opening, 
should you wish, as the information is readily available in the Output panel or from the report files 
produced during the build. 

Figure 36. Summarizing resource usage for the chosen device.

1 ­ 23 
Altium Designer Training Module  FPGA Design 

7.6.4  Program 
This stage of the process flow is used to 
download the design into the physical 
FPGA device on a NanoBoard or production 
board. This stage is only available when the 
Devices view is configured in Live mode. 
This stage of the flow can only be used 
Figure 37. Program FPGA stage of the process flow.  once the previous three stages have been 
run successfully and a programming file has 
been generated.  A green arrow will point to 
the device to be programmed in the Hard 
Devices Chain. 
As the programming file is downloaded to 
the device via the JTAG link, the progress 
will be shown in the Status bar. Once 
successfully downloaded, the text 
underneath the device will change from 
‘Reset’ to ‘Programmed’ (Figure 38) and 
any Nexus­enabled devices on the soft 
Figure 38. Successful programming of the physical FPGA device.  chain will be displayed as ‘Running’ (Figure 
39). 

Figure 39. Soft devices running after successful program download. 

7.7  Configuring a build stage 
Should you wish to configure any of the specific options associated 
with each of the different sub­stages in the FPGA build flow, you can 
do so by clicking on the appropriate configuration icon. 
Consider the case where you want to generate a PROM file for 
subsequent download to a Xilinx configuration device on a production 
board. In the process flow associated to the targeted FPGA device, 
expand the build section. The last entry in the build menu is Make 
PROM File 
Clicking on the  icon, to the far right of this menu entry, will open 
the Options for PROM File Generation dialog (Figure 41).  From 
here you can choose the non­volatile configuration device that will be 
used by the production board to store the FPGA configuration. 

Figure 41. Accessing the options dialog for PROM file generation.

1 ­ 24 
Altium Designer Training Module  FPGA Design 

7.8  How Altium Designer interacts with back­end vendor tools 
If you are already familiar with the build flows offered by Altera and Xilinx, you will be familiar with 
one or both of the following panels: 

Figure 42. Xilinx (left) and Altera (right) vendor tool interfaces. 

Although Altium Designer has its own HDL synthesizer, it is reliant on back­end vendor tools to 
implement the design on a specific device.  This makes sense, as it is the device vendors who have 
the most intimate knowledge of their specific devices and who have already developed well­proven 
targeting technologies. 
Most vendor specific tools have been developed in a modular fashion and contain a number of 
separate executable programs for each phase of the implementation process.  The vendor GUIs that 
are presented to the user are co­coordinating programs that simply pass the appropriate parameters 
to back­end, command­line programs. 
When it comes to FPGA targeting, Altium Designer operates in a similar fashion in that it acts as a 
coordinator of back­end, vendor­specific programs.  Parameters that need to be passed from the 
Altium Designer front­end to the vendor­specific back­end programs are handled by a series of text­ 
based script files.  Users who are already familiar with the back­end processing tools may find some 
use in accessing these script files should they wish to modify or ‘tweak’ interaction with back­end 
processing tools.  This however is considered a highly advanced topic and one that should be 
handled cautiously.  Ensure backups are taken prior to modification. 
The files controlling interaction with vendor­specific back­end tools can be found in the System 
directory under the Altium Designer 6 install directory.  The naming convention used for these 
files is: 
Device[Options | Script]_<vendor>[_<tool> | <family>].txt 
…so for example DeviceOptions_Xilinx_PAR.txt controls the default options for Xilinx’s Place 
and Route tool. 

7.9  Exercise 3 – Run MyPWM on the NanoBoard 
In this exercise we shall take our previously developed PWM design and run it on the NanoBoard. 
1.  Ensure that the NanoBoard is correctly connected to the PC, the XC3S1500­4FG676C daughter 
board is loaded, and the NanoBoard is switched on. 
2.  Open the Devices View and ensure the Live checkbox is ticked. 
3.  Click on the ‘label’ region of the Program FPGA button in the FPGA Build flow.  The design will 
begin building and may take a moment or two to complete. 
4.  If any build errors occur, diagnose and rectify the error and attempt the build process again. 
5.  Once downloaded, verify the operation of the design by switching different DIP switches off and 
on.  You should notice a change in the LED illumination.

1 ­ 25 
Altium Designer Training Module  FPGA Design 

8  Embedded instruments 
8.1  Overview 
So far we have built our PWM FPGA design and run it on the NanoBoard.  Fortunately this design 
provided an output on the LEDs that enabled us to immediately verify that the circuit was performing 
as we expected.  But how do we verify other designs?  In this section we will introduce the range of 
embedded instruments that can be integrated into FPGA designs to facilitate on­chip testing and 
debugging. 

8.2  On­Chip debugging 
A big concern of many embedded systems designers transitioning to FPGA based design is the 
issue of debugging; how does one see inside an FPGA circuit to diagnose a fault?  What they may 
not be aware of is that the flexibility of FPGA devices enables typical test and measurement 
instruments to be wired inside the device leading to far easier debugging than what has previously 
been possible. 
The Altium Designer system includes a host of ‘virtual’ instruments that can be utilized to gain 
visibility into the hardware and quickly diagnose elusive bugs.  These instruments can be found in 
the FPGA Instruments.IntLib integrated library.  The ‘hardware’ portion of the instrument is 
placed and wired on the schematic like other components.  Once the design has been built, real time 
interaction with each instrument is possible from the Devices View. 

Figure 43. Embedded instruments displayed in the devices view. 

The controls for the individual embedded instruments can be accessed by double­clicking their 
associated icon in the Devices View.

1 ­ 26 
Altium Designer Training Module  FPGA Design 

8.3  CLKGEN 

Figure 44. Frequency generator, used to generate the specified frequency 

The frequency generator outputs a 50% duty cycle square 
wave, of the specified frequency. Clicking the appropriate  U7 
button can choose a number of predefined frequencies, or a  TIMEBASE  FREQ 
custom frequency can be selected using the Other Frequency 
button. If the specified frequency cannot be generated the  Frequency Generator 
closest possible is generated and the error shown on the  CLKGEN 
display. Note that when the frequency generator is instantiated 
in the FPGA it will not be running, you must click the Run button to generate an output. 

8.4  CROSSPOINT_SWITCH 

Figure 45.Cross point switch, used to control the connection between input and output signals 
The CROSSPOINT_SWITCH device is a configurable signal  U18 
switching instrument which provides an efficient means by  Crosspoint Switch 
which to switch signals in a design.  AIN_A[7..0]  AOUT_A[7..0] 
AIN_B[7..0]  AOUT_B[7..0] 
The interconnection between input and output blocks is 
completely configurable. Initial connections can be defined as  BIN_A[7..0]  BOUT_A[7..0] 
BIN_B[7..0]  BOUT_B[7..0] 
part of design­time configuration, but can be changed on­the­ 
fly at run­time, from the device's associated instrument panel.  CROSSPOINT_SWITCH

The latter enables you to switch signals without having to re­ 
synthesize and download the entire design to the FPGA. 

8.5  FRQCNT2 

Figure 46. Frequency counter, used to measure frequency in the design 
U6 
The frequency counter is a dual input counter that can display the  FREQA 
measured signal in 3 different modes; as a frequency, period, or number of  FREQB 
pulses.  TIMEBASE 

Frequency Counter 
FRQCNT2 

1 ­ 27 
Altium Designer Training Module  FPGA Design 

8.6  IOB_x 

Figure 47. Digital IO module, used to monitor and control nodes in the design 

The digital I/O is a general­purpose tool that can be used for 
both monitoring and activating nodes in the circuit. It is 
available in either 8­bit wide or 16­bit wide variants, with 1 to 
4 channels. 
Each input bit presents as a LED, and the set of 8 or 16 bits 
also presents as a HEX value. Outputs can be set or cleared 
individually by clicking the appropriate bit in the Outputs display.  Alternatively typing in a new HEX 
value in the HEX field can alter the entire byte or word. If a HEX value is entered you must click the 
button to output it. The Synchronize button can be used to transfer the current input value to the 
outputs. 

8.7  DIGITAL_IO 

Figure 48. Configurable Digital IO module, used to monitor and control nodes in the design 

The configurable digital I/O is a general­purpose tool that can be 
Configurable Digital IO 
used for both monitoring and activating nodes in the circuit. 
InLEDs[7..0]  Rot[7..0] 
Unlike its legacy counterparts (IOB_x family of devices), with the  SpareOutB[7..0]  Zoom[7..0] 
DIGITAL_IO device you are not constrained to limited signals of  SpareOutC[7..0]  Flags[7..0]
8­ or 16­bits. Instead, any number of signals may be added, and  SpareOutD[7..0] 
any number of bits can be assigned to a single signal. You may 
also have different numbers of input and output signals. 

Each input bit can be presented in a range of different styles including LEDs, numeric, LED digits, or 
as a bar, and the set of bits also presents as a HEX value. Output styles can also vary and include 
LEDs, numeric, LED digits, and a slider.  Each output can have a predefined Initial Value and will 
also include a HEX display.  Outputs can be set or cleared individually and the method will vary with 
the style selected.  Alternatively typing in a new HEX value in the HEX field can alter the value of the 
output. If a HEX value is entered you must click the  button to output it. The Synchronize button 
can be used to transfer the current input value to the outputs. 

1 ­ 28 
Altium Designer Training Module  FPGA Design 

8.8  LAX_x 

Figure 49. The logic analyzer instrument at the top, with two variations of the configurable LAX shown below it. 
The LAX component on the left has been configured to accept 3 different sets of 64 signals (signal sets), the 
one on the right has one signal set of 16 bits. The Configure dialog is used to set the capture width, memory 
size and the signal sets. 

The logic analyzer allows you to capture multiple snapshots of multiple nodes in your design. Use 
the LAX to monitor multiple nets in the design and display the results as a digital or an analog 
waveform. 
The LAX is a configurable component. Configure it to simultaneously capture 8, 16, 31 or 64 bits. 
The number of capture snapshots is defined by the amount of capture memory; this ranges from 1K 
to 4K of internal storage memory (using internal FPGA memory resources). It can also be configured 
to use external memory. This requires you to wire it to FPGA memory resources or to off­chip 
memory (e.g. Desktop NanoBoard Memory). 
After placing the configurable LAX from the library, right­click on the symbol and select Configure 
from the floating menu to open the Configure (logic analyzer) dialog, where you can define the 
Capture width, memory size and the signal sets. 
The Configurable LAX includes an internal multiplexer, this allows you to switch from one signal set 
to another at run time, displaying the capture data of interest. You can also trigger off one signal set 
while observing the results of another set. 
Note that the FPGA Instruments library includes a number of LAX components. The LAX 
component is the configurable version, all others are legacy versions.

1 ­ 29 
Altium Designer Training Module  FPGA Design 

8.8.1  Waveform display features 

Figure 50. Digital waveform capture results from the logic analyzer 

Figure 51. Analog waveform capture results from the logic analyzer 

The capture results are displayed in the instrument panel. There are also two waveform display 
modes. The first is a digital mode, where each capture bit is displayed as a separate waveform and 
the capture events define the timeline. Note that the capture clock must be set in the logic analyzer 
options for the timeline to be calculated correctly. Click the Show Digital Waves button to display 
the digital waveform. 
The second waveform mode is an analog mode, where the value on all the logic analyzer inputs is 
displayed as a voltage, for each capture event. The voltage range is from zero to the maximum 
possible count value, scaled to a default of 3.3V. Click the Show Analog Waves button to display 
the analog waveform. 

8.8.2  Zooming in and out 
In both the analog and digital waveform viewers it is possible to zoom in and out by hitting the Page 
Up or Page Down keys respectively 

8.8.3  Continuous display mode 
Waveforms captured by the logic analyzer can be displayed as a single pass or as a continuously 
updated display.  Continuous updates can be enabled / disabled from the logic analyzer toolbar. 

Figure 52. Enabling the continuous capture mode.

1 ­ 30 
Altium Designer Training Module  FPGA Design 

8.9  Terminal Console 

Figure 53. Terminal console instrument rack functions as a debug console for embedded applications. 

The TERMINAL device is a debug console which allows you to type text  U1 
directly in its associated instrument panel and send it directly to the  Terminal Console 
processor in your design, to be handled by the embedded software code  STB_I 
CYC_I 
running therein. Conversely, it allows the display of text sent from that  ACK_O 
ADR_I[3..0] 
processor.  Although classed as one of Altium Designer's virtual  DAT_O[7..0] 
instruments, the TERMINAL device is really a hybrid – part instrument and  DAT_I[7..0] 
part Wishbone­compliant slave peripheral. Whereas other instruments are  WE_I 
configured and operated directly from a GUI, the TERMINAL device  CLK_I 
RST_I 
requires interaction at the code level, to initialize internal registers and to  INT_O[1..0] 
write to/read from its internal storage buffers.  TERMINAL

8.10  Exercise 4A – Using embedded instruments 
A working design of a PWM circuit complete with embedded instruments has been prepared to 
illustrate the features of FPGA instruments.  Your instructor will tell you where to find it on your local 
hard drive. 
U5 
CLK_BRD  CLK_BRD 
CLK_BRD  CLK  STATUS 
CLK_TICK 
CLK_CAP 
IA[7..0]  O[15..0] 
CHANNELS[15..0] 
U6 
IB[7..0] 
TRIGGER 
J8B2_16B 
U7 
CLK_BRD  U1  Logic Analyser 
TIMEBASE  FREQ 
VCC  CB8CEB  LAX_1K16 
Frequency Generator  Q[7..0] 
CLKGEN 
CE CEO 
CLK_TICK 
C  TC 
CLR 
U3 
I0  U4  O[7..0] 
U2  A[7..0]  GT  LEDS[7..0] 
I1 
B[7..0]  LT 
I2 
TEST_BUTTON 
COMPM8B  I3 
INV  I4 
I5 
I6 
U8  I7 
AIN[7..0]  AOUT[7..0]  J8S_8B 

1 Ch x 8 Bit Digital IO  U9 
GND 
IOB_1X8  FREQA 
CLK_TICK 
FREQB 
CLK_BRD 
TIMEBASE 

Frequency Counter 
JTAG_NEXUS_TDI  TDI  J TAG  FRQCNT2 
J TAG 
JTAG_NEXUS_TDO  TDO 
J TAG 
JTAG_NEXUS_TCK  TCK  J TAG 
JTAG_NEXUS_TMS  TMS 
. . . 
J TAG 

J TAG 
VCC  TRST 

Figure 54. PWM circuit with several embedded instruments connected. 

1.  Open the provided project and download it to your NanoBoard. 
2.  Follow on your own circuit as the instructor discusses the various embedded instruments. 

1 ­ 31 
Altium Designer Training Module  FPGA Design 

3.  Double­click the NanoBoard icon in the Devices View to open the instrument rack for the 
NanoBoard and set its clock frequency to 50MHz. 

Figure 55. NanoBoard controller. 

4.  Open the frequency generator’s 
instrument panel.  If the time base 
indicated in the window next to the 
Set Time Base button is not 50 
MHz then press the Set Time 
Base button to open a dialog box 
that will enable you to set it 
correctly.  The Require 50/50 
Duty checkbox should be 
checked. 
The frequency generator should 
be set to 1MHz as indicated in 
Figure . 

Figure 56. Counter options dialog 

Figure 57. Frequency generator Panel 

5.  Open the frequency counter’s 
instrument panel.  Select the 
Counter Options button on the 
frequency counter module and 
make sure the Counter Time Base 
is also set to 50MHz (the same as 
the NanoBoard clock frequency), 
as shown in Figure 57. Press OK. 
Use the Mode button as necessary 
on each channel of the frequency 
counter module to toggle the 
display mode between frequency, 
period or count.  You should get a 
similar display to what is depicted 
in Figure 59. 

Figure 58. Counter options dialog

1 ­ 32 
Altium Designer Training Module  FPGA Design 

Figure 59. Frequency counter control panel 

6.  Open the Digital IOB’s instrument panel. 

Figure 60. Digital IOB instrument control panel 

7.  Modify the Outputs of the IOB module and observe changes in the LEDs. 
8.  Adjust the output frequency of the frequency generator module to a lower frequency; try 1KHz. 
Observe the impact this has on the LEDs.  Modify the Outputs of the IOB and observe further 
changes in the LEDs. 
9.  Adjust the output frequency of the frequency generator module back to 1MHz. 
10.  Open the logic analyser’s instrument control panel. 

Figure 61. Logic analyser instrument control panel 

11.  Select Show Panel on the logic analyzer.  Set the panel up as depicted in Figure 62. 

Figure 62. Logic analyser triggering options.

1 ­ 33 
Altium Designer Training Module  FPGA Design 

12.  Select Options on the logic 
analyser.  Set the clock capture 
frequency to 1MHz – the same as 
the frequency generator module. 
Adjust the other controls to be the 
same as shown in Figure 63. 
13.  Select Arm and observe the 
waveform displayed in the waveform 
viewer.  Select Continuous Capture 
from the Logic Analyzer menu and 
adjust the IOB output.  Observe the 
change in the PWM mark­to­space 
ratio. 

Figure 63. Logic analyser setup options. 

Figure 64. Logic analyzer waveform with bit­7 of the IOB set. 

Figure 65. Logic analyzer waveform with bits 6 & 7 of the IOB set.

1 ­ 34 
Altium Designer Training Module  FPGA Design 

8.11  Where are the Instruments? 
The important differentiator between Altium Designer’s embedded instruments and other simulation­ 
based virtual instruments is that Altium Designer’s embedded instruments are true physical devices 
that are downloaded into the FPGA device as part of the design.  The information provided to the 
designer by the embedded instruments can be relied upon as it is taken from real physical 
measurements taken on chip. 
Figure illustrates this point as it shows the FPGA real estate used by the embedded instruments. 

Figure 66. Floorplan of MyPWM.SchDoc after it has been placed onto an FPGA. 

8.12  Enabling embedded instruments 
The NanoBoard hardware incorporates the entire infrastructure necessary to support Embedded 
Instruments and allow them to communicate with the host PC. All virtual instruments communicate 
with the host PC via a ‘soft’ JTAG chain that conforms to the Nexus standard.  To enable Nexus on 
the NanoBoard, the NEXUS_JTAG_PORT and NEXUS_JTAG_CONNECTOR must be placed onto the 
top level schematic.  These respective components can be found in the FPGA Generic.IntLib 
and FPGA NB2DSK01 Port­Plugin.IntLib Integrated Libraries.

1 ­ 35 
Altium Designer Training Module  FPGA Design 

NEXUS_JTAG_PORT  NEXUS_JTAG_CONNECTOR 
JTAG 
TDI  JTAG_NEXUS_TDI 
JTAG 
JTAG 
TDO  JTAG_NEXUS_TDO 
JTAG  TCK  JTAG_NEXUS_TCK 

JTAG  TMS  JTAG_NEXUS_TMS 


JTAG 
TRST  VCC 

Figure 67. NEXUS JTAG Port and NEXUS JTAG Connector. 

To be able to use embedded instruments in custom designs, it is necessary to reserve 4 device pins 
for the NEXUS_JTAG_CONNECTOR and ensure that sufficient device resources are present to 
accommodate the virtual instruments in the device.  The JTAG soft chain and other communications 
chains present on the NanoBoard will be discussed further in the next section.

1 ­ 36 
Altium Designer Training Module  FPGA Design 

9  Interacting with the NanoBoard 
9.1  Overview 
The NanoBoard is pivotal to rapid embedded systems development with Altium Designer. It contains 
a range of peripherals and expansion capabilities to allow it to adapt to a broad cross section of 
embedded projects. In this section we will discuss the concepts necessary for a designer to make 
effective use the NanoBoard’s potential. 

9.2  NanoBoard communications 
The NanoBoard contains 3 primary communication channels. A complete understanding of these 
channels is not necessary to begin using the tool suite however it may be of interest to developers 
keen to make use of Altium Designer’s debugging capabilities on their own custom designs. 
The primary point of user control of the NanoBoard is via the Devices View.  This view provides an 
easy­to­use visualization of the various communications chains active on the NanoBoard. 

NanoTalk 
Chain 

JTAG 
Hard 
Chain 

JTAG 
Soft 
Chain

Figure 68. Devices view with its various communications channels highlighted. 

1 ­ 37 
Altium Designer Training Module  FPGA Design 

9.2.1  NanoTalk chain 
NanoTalk is the proprietary communications protocol developed by Altium to enable multiple 
NanoBoards to communicate with one another.  The 10 pin NanoTalk headers can be found on both 
the left and right edges at the upper end of the Desktop NanoBoard.  Communications via this 
channel is totally transparent to the user.  There should be no need to interact with this standard. 

9.2.2  JTAG Hard Chain 
The JTAG Hard Chain is a serial communications channel that connects physical devices together. 
JTAG devices can be connected end on end by connecting the TDO pin of an upstream device to 
the TDI pin of a downstream device.  The hard JTAG chain is visible in the middle portion of the 
Devices View.  Usually this is where an FPGA will be located however if you also have other 
devices that are connected to the JTAG chain such as a configuration device then these will be 
visible also. 
The hard JTAG chain can be extended beyond the NanoBoard through the User Board A and User 
Board B connectors.  When using either of these connectors, it is imperative that the JTAG chain is 
not broken – i.e. the TDI/TDO chain must be looped back to the NanoBoard. 

9.2.3  JTAG Soft Chain 
The JTAG Soft Chain is a separate JTAG channel that provides communication with the Embedded 
Instruments that can be incorporated into an FPGA design.  This chain is labeled as a soft chain 
since it does not connect tangible physical devices together but rather connects soft or downloadable 
instruments that reside inside a hard or physical FPGA device. 

9.3  Technical background 
TD 
T DI 

JT 
J TA 
AG 

P
P a a rr a
a ll ll e
e l  Ce 
C el 
ll 

D
D a
a tt a  FF ll o o w 

TD 
T DO 
O
Figure 69. Conceptual View of JTAG data flows. 

9.3.1  JTAG in depth 
The acronym JTAG stands for Joint Test Application Group and is synonymous with IEEE 1149.1. 
The standard defines a Test Access Port (TAP), boundary scan architecture and communications 
protocol that allows automated test equipment to interact with hardware devices.  Essentially it 
enables you to place a device into a test mode and then control the state of each of the device’s pins 
or run a built­in self­test on that device.  The flexibility of the JTAG standard has also lead to its 
usage in programming (configuring) devices such as FPGAs and microprocessors. 
At minimum, JTAG requires that the following pins are defined on a JTAG device: 
TCK: Test Clock Input 
TMS: Test Mode Select 

1 ­ 38 
Altium Designer Training Module  FPGA Design 

· TDI: Test Data Input
· TDO: Test Data Output 
TCK controls the data rate of data being clocked into and out of the device.  A rising TCK edge is 
used by the device to sample incoming data on its TDI pin and by the host to sample outgoing data 
on the devices TDO pin. 

Figure 70. Using JTAG Chain to connect multiple JTAG devices together in a digital design. 

Figure 70. JTAG Test Access Port (TAP) State Machine. 

The Test Access Port (TAP) Controller is a state machine that controls access to two internal 
registers – the Instruction Register (IR) and the Data Register (DR).  Data fed into the device via TDI 
or out of the device via TDO can only ever access one of these two registers at any given time.  The 
register being accessed is determined by which state the TAP controller is in.  Traversal through the 
TAP controller state machine is governed by TMS.

1 ­ 39
Altium Designer Training Module  FPGA Design 

9.3.2  Nexus 5001 
The flexibility of JTAG for hardware debugging purposes has flowed over into the software domain. 
In the same way that test engineers have sought a standardized method for testing silicon, software 
engineers have also sought a standardized means for debugging their programs. 
In 1998, the Global Embedded Debug Interface Standard (GEDIS) Consortium was formed.  In late 
1999 the group moved operations into the IEEE­ISTO and changed their name to the Nexus 5001 
Forum and released V1.0 of IEEE­ISTO – 1999.  In December 2003, V2.0 was released. 
The Nexus 5001 standard provides a standardized mechanism for debug tools to interact with target 
systems and perform typical debugging operations such as setting breakpoints and analyzing 
variables, etc.  There are 4 classes of Nexus compliance – each with differing levels of supported 
functionality.  The lowest level uses JTAG as the low­level communications conduit. 
The implementation of Nexus 5001 on the Desktop NanoBoard has been labeled as the JTAG Soft 
Chain.  It is a serial chain just like the hard chain however rather than connecting physical devices 
together, it connects virtual devices together.  These devices include the set of virtual instruments 
that are supplied with Altium Designer and described in the following chapter.  Control of devices on 
the Soft Chain can be performed from the Devices View – Soft Chain Devices are located towards 
the bottom of the Devices View under the Hard Chain. 
As with the JTAG Hard Chain, the Soft Chain can be taken off the NanoBoard via the User Board A 
and User Board B connectors.  This provides the means for target systems to also include virtual 
instruments and to benefit from the Altium Designer development environment.  Similarly to the Hard 
Chain, it is imperative that a complete loop be maintained between the Soft Chain TDI and TDO 
connections. 

9.4  The NanoBoard controller 
The NanoBoard Controller can be accessed by double­clicking on the NanoBoard icon in the 
Devices View. 

Figure 71. The NanoBoard Controller Instrument Rack. 

P182
P182  CLK_BRD 
The Clock Frequency indicated in the window will be supplied to the 
CLK_BRD port on the NanoBoard.  Accessing this clock on custom designs is 
as simple as placing the CLOCK_BOARD component from the FPGA NB2DSK01 Port­ 
Plugin.IntLib Library. 
Selecting a non­standard frequency is possible by clicking the Other Frequency button.  The 
NanoBoard clock system employs a serially programmable clock source (part number ICS307­02) 
that is capable of synthesizing any clock frequency between 6 and 200MHz.  Advanced access to 
the Clock Control IC registers is available through the Clock Control Options button.  A datasheet 
for this device is available from the ICS website http://www.icst.com/products/pdf/ics3070102.pdf. 
An online form useful for calculating settings for the clock control IC is also available at 
http://www.icst.com/products/ics307inputForm.html. 

To the right of the NanoBoard Controller is a section with the heading 
Flash RAM.  The FPGA Boot button affords the facility to store a daughter 
board configuration file that will get automatically loaded into the daughter 
board on power up.  The Embedded button exposes memory that can be 
used by the user application to store non­volatle user data.  The 
Embedded Memory device is accessible via the SERIALFMEMORY component in the FPGA 
NB2DSK01 Port­Plugin.IntLib Library. 

1 ­ 40 
Altium Designer Training Module  FPGA Design 

9.5  FPGA I/O view 
To display the Instrument rack for a device, double­click on the device in the JTAG Hard chain. 
Clicking on the JTAG Viewer Panel button then brings up the JTAG Viewer Panel. 

Figure 72. The Hard Devices instrument rack. 

Figure 73. The FPGA I/O Instrument Rack and JTAG Viewer Panel. 

This interface enables the developer to see in real time the flow of signals across the device’s pins. 
This can be particularly useful when ensuring that signals are being correctly propagated to and from 
the device. 
Placing a tick in the Live Update checkbox will cause the display to update in real time. 
Alternatively, leaving the Live Update checkbox clear and selecting the update icon will cause 
signal information to be latched to the display and held. 
Check Hide Unassigned I/O Pins to remove clutter from the display. 
The BSDL Information drop down list should only need to be accessed for devices which are 
unknown to Altium Designer.  In this case, you will need to provide the location of the vendor 
supplied BSDL file for the device you are viewing. 
The FPGA IO instrument rack is available for all devices on the JTAG Hard Chain – including 
devices on a user board that is connected to the JTAG Hard Chain.

1 ­ 41 
Altium Designer Training Module  FPGA Design 

9.6  Live cross probing 
Probe directives can be placed on the FPGA 
schematic on any I/O net and will update in real time 
as long as the Hard Devices Instrument Panel is 
displayed.  Use the Place » Directives » Probe to 
place a cross probe on one of the I/O nets. 
Figure 74. Using Live Cross Probing. 

9.7  Exercise 4B – View MyPWM on the NanoBoard 
1.  Reload your circuit from Exercise 3 again and run it on the NanoBoard. 
2.  Open the JTAG Viewer Panel. 
3.  Check the Hide Unassigned I/O Pins checkbox and the Live Update checkboxes. 
4.  Observe the change in switch states and LEDs as you toggle the NanoBoard DIP switches. 
5.  Use the Place » Directives » Probe option to place a probe point on the bus connected to the 
DIP Switches.  Observe the probe value as the DIP Switches are changed on the NanoBoard.

1 ­ 42 
Altium Designer Training Module  FPGA Design 

10  Creating a core component 
10.1  Core project 
Altium Designer provides the ability to encapsulate an entire FPGA circuit into a single component 
that can be used as a building block in other projects.  These self­contained blocks are called core 
components and offer the advantage of design reuse and design security.  Core components can be 
synthesized for a target FPGA and made available to others without exposing the underlying IP. 
A core project is used to create an FPGA component that may be used multiple times within one or 
across many FPGA projects.  The output of a core project behaves in a similar fashion to a library 
component in that it becomes an elemental unit that is used as a component in larger designs. 
A core project is useful when you wish to make some functionality available to a broad user base but 
you do not want to expose the IP used to implement the functionality. 

Figure 75. Using a core component in an FPGA Project. 

10.2  Creating a core component from an FPGA project 
It is possible to create a core component from scratch however often we wish to create a core 
component from an existing FPGA design or project.  In either case a blank core project must first be 
created.  If the core component is to be based on an existing design then use Project » Add 
Existing to Project to add the relevant VHDL, Verilog and / or schematic documents to the project. 
If the core component is being created from scratch then its source documents will need to be 
created in the same way that an FPGA project is built.

1 ­ 43 
Altium Designer Training Module  FPGA Design 

10.3  A word about EDIF 
EDIF is an acronym for Electronic Design Interchange Format.  It was originally developed as a 
standardized format for transferring integrated circuit design information between vendor tools. 
Altium Designer creates EDIF files as part of the synthesis process and these files are then passed 
to the vendor back end tools for complete FPGA place and route. 
Although EDIF files conform to a standard, the information within a given EDIF file may contain 
vendor specific constructs.  EDIF files can not, therefore be considered as vendor independent. 
It is also worth noting that although EDIF files do offer some form of IP protection, they are readable 
by humans and can be deciphered with little effort.  They should not be relied upon to maintain IP 
protection. 

10.4  Setting up the core project 
Once the core project has been created it is important to make available its EDIF models when you 
eventually publish it.  Make sure the Include models in published archive checkbox is ticked in the 
Options tab of the Project Options dialog. 

Figure 76. Setting options for a core component. 

You must now specify the folder on your hard disk that you wish the EDIF models to be saved into. 
This folder will be searched along with the standard system EDIF folders (\Altium Designer 
6\Library\EDIF) when you synthesize any design.  It is good practice to keep EDIF models generated 
from core projects in a single location for easier searching.  To specify the location of the user 
presynthesized model folder, open the Preferences dialog, and navigate to FPGA > Synthesis.

1 ­ 44 
Altium Designer Training Module  FPGA Design 

Figure 77.  Specifying the location of core component models. 

10.5  Constrain / configure 
The concept of constraint files and configurations is central to the flexibility of Altium Designer.  They 
provide a mechanism to allow FPGA circuits to be developed independent of the final physical 
implementation.  Rather than storing device and implementation specific data such as pin allocations 
and electrical properties in the source VHDL or schematic documents, this information is stored in 
separate files – called Constraint files. This decoupling of the logical definition of an FPGA design 
from its physical implementation allows for quick and easy re­targeting of a single design to multiple 
devices and PCB layouts. 
There are a number of classes of configuration information pertinent to different aspects of an FPGA 
project: 

10.5.1 Device and board considerations: 
The specific FPGA device must be identified and ports defined in the top level FPGA design must be 
mapped to specific pin numbers. 

10.5.2 Device resource considerations: 
In some designs it may be advantageous to make use of vendor specific resources that are unique 
to a given FPGA device.  Some examples are hardware multiplication units, clock multipliers and 
memory resources.

1 ­ 45 
Altium Designer Training Module  FPGA Design 

10.5.3 Project or design considerations: 
This would include requirements which are associated with the logic of the design, as well as 
constraints on its timing.  For example, specifying that a particular logical port must be allocated to 
global clock net, and must be able to run at a certain speed. 
A configuration is a set of one or more constraint files that must be used to target a design for a 
specific output.  The migration of a design from prototype, refinement and production will often 
involve several PCB iterations and possibly even different devices.  In this case, a separate 
configuration would be used to bring together constraint file information for each design iteration. 
Each new configuration (and its associated constraint file(s) is stored with the project and can be 
recalled at any time. 
To summarize:
· Constraint files store implementation specific information such as device pin allocations and 
electrical properties.
· A Configuration is a grouping of one or more constraint files and describes how the FPGA 
project should be built. 

10.6  Creating a new constraint file 
When targeting a design for a user board, it is often necessary to manually create at least one 
constraint file.  This constraint file would include at a minimum the device that is being targeted and 
may include any number of additional constraints appropriate for the target PCB.  As cores may 
often be synthesized for a number of possible targets, it is useful to discuss the process of manually 
constraining and configuring a design in the context of creating core projects. 
Before a configuration can be built, a constraint file must exist.  Constraint files have the extension 
.Constraint. Constraint files for use with the Desktop NanoBoard can be found in the \Program 
Files\Altium Designer 6\Library\Fpga\ directory.  In general it is advisable to take a copy 
of these files and store it in your project directory before adding it to the project.  This way the project 
is kept self­contained and any edits you may inadvertently make will not affect the supplied 
constraint file.
· To add your own, new constraint file, right click on the project name in the Projects panel and 
select Add New To Project » Constraint File.
· A new blank constraint file will appear.  To specify the target device select Design » Add/Modify 
Constraint » Part and the Browse Physical Devices dialog will open. 

Figure 78. The Browse Physical Devices dialog, where you select the target FPGA.

1 ­ 46 
Altium Designer Training Module  FPGA Design 

Figure 79. Basic constraint file.

· Select the vendor, family, device and 
temperature/speed grades as desired and click 
OK.  A line similar to the one above will be 
automatically inserted into the constraint file:
· Save the constraint file.  Typically it would be 
named to reflect its role – for example if the 
target device was a Xilinx Spartan­3 FPGA 
mounted on your project PCB you might call it 
MyProject_Spartan3_1500.Constraint. 
You will notice the constraint file has been 
added to the project under the settings tab. 

Figure 80. Project with constraint File. 

10.7  Creating a configuration 
As previously mentioned, configurations group a number of constraint files together to create a set of 
instructions for the FPGA build process.  To define a configuration:
· Right­click on the project name in the Projects panel and select Configuration Manager 

Figure 81. Specifying a configuration using the configuration manager.

· If you have just recently created a new constraints file, you will see it listed under the Constraint 
Filename.  Existing constraint files that currently aren’t in the project can be added by selecting 
the Add button next to the Constraint Files text.
· To define a new configuration, select the Add button next to the Configurations text.  A dialog 
will appear requesting you to provide a name for the new configuration.  The name can be 
arbitrary but it is helpful if it provides some indication as to what the configuration is for.

1 ­ 47 
Altium Designer Training Module  FPGA Design 

· Having defined the new configuration, you may now assign constraint files to it by ticking their 
associated checkbox.  Here we have assigned the constraint file MyConstraint_Spartan3_1500 
to the Target_XC3S1500 configuration.
· Click OK to save the configuration. 

Figure 82. Specifying a configuration using the configuration manager. 

Although the above simplistic example only had one constraint file and one configuration, the power 
of configurations really becomes apparent as the design matures.  Below we see how a design has 
been targeted to multiple platforms: 

Figure 83. Example of a project with multiple configurations defined. 

Configurations can be updated or modified as desired at any time throughout the project’s 
development by returning to the Configuration Manager dialog. 

10.8  Synthesize 
Now that we have defined a configuration 
we are ready to synthesize the core for the 
target.
· With the top level FPGA document open 
select Design » Synthesize.  If we had 
defined more than one configuration and 
wished to synthesize all configurations at 
once we could select Design » 
Synthesize All Configurations.
· If you have not already nominated the 
top level entity/configuration in the 
Synthesis tab of the Options for Core  Figure 84. Specifying an FPGA project’s top level document.
Project, the Choose Toplevel dialog will 
appear.  Enter the core project name or select from the dropdown list and click OK to continue.
· The project will be synthesized resulting in the generation of VHDL files for the schematic, EDIF 
files for the schematic wiring and parts, and a synthesis log file.  These will all be located under 
the Generated folder in the project panel.
· You will observe the configuration name in brackets beside the Generated Folder.  Had we 
synthesized more than one configuration then a separate Generated folder would have appeared 
for each of the defined configurations. 

1 ­ 48
Altium Designer Training Module  FPGA Design 

· Confirm that the synthesis process completed 
successfully by observing the synthesis log file. 
A line towards the bottom of the report should 
indicate whether any errors were encountered. 

10.9  Publish 
Now we can publish the core project.  This will zip 
together (archive) all the EDIF files in the core 
project’s Project Outputs folder and then copy this 
to the user EDIF models folder that was specified 
earlier.
· Select Design » Publish.  If the error message 
“cannot find ‘working folder’” appears, make 
sure you have set up the Use presynthesized 
Figure 85. Files generated after synthesizing the design
model folder option in the FPGA Preferences 
dialog.
· Check the Messages panel to ensure the design has been successfully published.
· Save the core project file. 

10.10  Creating a core schematic symbol 
The core project has been successfully synthesized and published.  It would be possible at this point 
for other personnel to make use of your core through a VHDL instantiation process.  This can be a 
messy affair.  A far simpler option would be for them to use a schematic symbol that is linked to your 
core and associated EDIF files.  To do this, we need to create our own schematic symbol from the 
core component.
· With the top level FPGA document open select Design » Generate Symbol. 

Figure 86. Creating a core component symbol.

· Click Yes when you are asked if you want to create a new schematic library.  A popup will appear, 
where you can specify the appearance of the newly generated symbol. A new schematic library 
(Schlib1.SchLib) will be automatically created and opened to display the generated symbol.  By 
default the component name will take on the same name as the core project name.

1 ­ 49 
Altium Designer Training Module  FPGA Design 

Figure 87. Specifying core component options.

· From within the library editor, select the component in the Library panel and select the Edit 
button.  The Library Component Properties dialog will be displayed.  Note that several 
parameters have been added to indicate which child models are required to be retrieved from the 
published EDIF zip files. 

Figure 88. Specifying the properties of the newly created core component symbol.

· Clicking on the Edit Pins button will enable further modification of the properties and appearance 
of the schematic symbol.
· From the schematic library editor, adjust the symbol properties as appropriate and save the 
component.  Save the library before exiting.

1 ­ 50 
Altium Designer Training Module  FPGA Design 

Figure 89. Editing the core component pins. 

10.11  Using a core component 
When a core component is synthesized and published, the EDIF model is archived into the location 
specified in the FPGA Preferences dialog.  Any project that subsequently uses the core component 
must ensure that the EDIF archive can be found within the search path.  The search sequence for 
EDIF models is: 
$project_dir 
$user_edif\$vendor\$family 
$user_edif\$vendor 
$user_edif 
$system_edif\$vendor\$family 
$system_edif\$vendor 
$system_edif 
Note that the search locations includes the project directory which makes it useful if you need to 
transfer the design to another PC that does not have the user EDIF models location defined.

1 ­ 51 
Altium Designer Training Module  FPGA Design 

10.12  Exercise 5 – Create a core component from MyPWM 
1.  Create a new core project and call it MyPWMCore.PrjCor. Note that the filename must not have 
spaces in it. 
2.  Set the “Include models in published archive” checkbox in the Project Options dialog. 
3.  In the Preferences dialog, go to FPGA – Synthesis, and select an output path for EDIF files. 
This path should not include any spaces. 
4.  Attach the existing MyPWM.SchDoc that you created as part of exercise 3. 
5.  Create a project level constraint file and call it MyPWMPrj.Constraint.  Add the following to this 
constraint file: 
Record=Constraint | TargetKind=Port | TargetId=CLK_BRD | FPGA_CLOCK_PIN=True 
Record=Constraint | TargetKind=Port | TargetId=CLK_BRD | FPGA_CLOCK=True 
Record=Constraint | TargetKind=Port | TargetId=CLK_BRD | FPGA_CLOCK_FREQUENCY=50Mhz 
Figure 90. Updates to be made to MyPWMPrj.Constraint file. 

6.  Create a constraint file each for an Altera Cyclone II device as well as a Xilinx Spartan 3 device. 
7.  Create a configuration that links each of the individual device constraint files with the project 
constraint file. 
8.  Synthesize all configurations and publish the design.  Check the User Presynthesized model 
Folder (as set in Step 3) using windows explorer and view the directories that are created and 
their contents. 
9.  Create a core schematic symbol and save it to the library MyCoreLib.SchLib 
10.  Create a new FPGA project and schematic that makes use of your PWM core and test it on the 
NanoBoard. 
U1 
CLK_BRD 
CLK_BRD  LEDS[7..0]  LEDS[7..0] 
ON 

SW[7..0]  SW[7..0] 
1  2  3  4  5  6  7  8 

TEST_BUTTON 
TEST_BUTTON 
MyPWMCore 

Figure 90. Test project used to test the function of MyPWMCore.

1 ­ 52 
Altium Designer Training Module  FPGA Design 

11  FPGA design simulation 
Altium Designer supports behavioral simulation of VHDL designs.  This is particularly useful when 
verifying the functional operation of digital circuits prior to implementing them inside an FPGA. 

11.1  Creating a testbench 
Before simulation can begin, a VHDL Testbench file must be created to drive the simulation 
session.  Conceptually, the Testbench straddles the Design Under Test (DUT) and drives the DUT’s 
inputs whilst observing its outputs. 

VHDL Testbench 

DUT  Design Under Test (DUT)  DUT 


Inputs  Outputs

Figure 91. Conceptual view of how a VHDL testbench interacts with the Design Under Test (DUT). 

Altium Designer provides a convenient method for building a VHDL Testbench based on the inputs 
and outputs of the nominated DUT.  A shell testbench file can be automatically created by the 
system.
· Open a schematic document and select Tools » Convert » Create VHDL Testbench 
from the menu.
· Open a VHDL document and select Design » Create VHDL Testbench. 
A new VHDL document will be created with the extension .VHDTST and will be added to the project. 
Within the Testbench file will be a comment  “—insert stimulus here”.  By placing VHDL code at this 
point you can control the operation of the simulation session. At a minimum, the Testbench must set 
all of the DUT’s inputs to a known state.  If the DUT requires a clock then that too must be provided 
by the Testbench.  Most simulation errors occur as a result of the Testbench failing to properly 
initialize the inputs of the DUT. 

11.2  Assigning the Testbench Document 
Once you have created the Testbench file but before a simulation can begin, Altium Designer needs 
to be formally told which VHDL document in the project will be used to drive the simulation.  Select 
Project Options by right clicking on the FPGA project in the Projects panel or use the menu to 
select Project » Project Options Select the Simulation tab from within the Project Options dialog 
and select the appropriate Testbench Document from the drop­down list. 

Figure 9218. Specifying the testbench document 

1 ­ 53 
Altium Designer Training Module  FPGA Design 

11.3  Initiating a simulation session 
A simulation session can be initiated by 
selecting Simulator » Simulate from the 
menu or by clicking the simulation button 
in the VHDL Tools toolbar whilst a VHDL 
document is active in the main window. 

11.4  Project compile order 
When you first run a simulation from a testbench, Altium Designer may need to establish the 
compilation order of the VHDL documents.  Whilst performing this process, you may see an error 
appear in the Messages panel with the message: “Unbound instance DUT of component …”  Do not 
be concerned as this is normal when you first run a simulation. 

Figure 93. Messages panel. 

After a brief moment, a dialog may appear 
prompting you to specify the top level 
document for simulation (Figure 94). 
The compilation order of the project can be 
changed at a later time if necessary by 
selecting Project » Project Order  or by right 
clicking on the FPGA project in the Projects 
panel and selecting Project Order. 

Figure 94. Choosing the top level document.

1 ­ 54 
Altium Designer Training Module  FPGA Design 

11.5  Setting up the simulation 
display 
The Simulation Signals dialog (Figure 95) is 
automatically presented at the beginning of a 
simulation or it can be accessed via Simulator » 
Signals. 
The Watch Name is the name of the signal declared 
inside the block of VHDL code. 
Signals must be Enabled in order to be a part of the 
simulation.  Furthermore, if they need to be 
displayed as part of the simulation output then 
Show Wave must also be selected. 
The Waveform viewer (Figure 95) provides a 
visualization of the status of each of the displayed 
signals.
· The icon  next to the bus name indicates a bus 
signal.  Clicking on this icon will expand the bus 
into its individual signals for closer inspection.
· The time cursor (indicated by the purple vertical 
bar) can be dragged along the time axis via the 
mouse.  The current position of the cursor is 
provided in the time bar across the top of the 
Figure 9519. Specifying signals to display in the  display.
simulation. 
· Zooming in or out is achieved by pressing the 
Page Up or Page Down keys respectively.
· The display format of the individual signals can 
be altered via the menu item Tools » Format 
and Radix. 

Figure 96. The waveform viewer

1 ­ 55 
Altium Designer Training Module  FPGA Design 

11.6  Running and debugging a simulation 
Running a simulation is reasonably straightforward with all the 
stepping/running functions that you might wish to use being 
available from the Simulator menu or the VHDL Tools toolbar.
· Run Forever will run the simulation indefinitely until Stop is 
pressed. This command is used to run a VHDL simulation until 
there are no changes occurring in the signals enabled in the 
simulation.
· Use the Run (for a time step) command to run the current 
simulation for a user­specified period of time (time step).
· Run for  (the last time step) will run the simulator for the same 
period of time as specified in the last Run command.
· Run to Time will run the simulator to an absolute time. 
Selecting a time prior to where the simulation has already 
simulated to will cause the simulator to do nothing.
· Run to Cursor is useful when debugging VHDL source and 
will cause the simulator to run until the defined cursor location 
is encountered in a source VHDL document. The simulator will 
simulate everything up to the selected line. Make sure that the 
Show execution point option is enabled, in the Debugging 
Options region of the FPGA – Simulation Debugger page of 
the Preferences dialog (Figure 97).
· Custom Step (Run simulation to the next debug point): This 
command is used to run the current simulation, up to the next 
executable line of code in the source VHDL documents. The 
next executable code point can be anywhere in the code and 
therefore the command can be considered to be stepping 
Figure 97. The simulator menu
through the code in parallel, rather than the sequentially­based 
step into and step over commands.
· Step Time: This command is used to run the current simulation, executing code in the source 
VHDL documents until time increments – i.e. all delta time events prior to the next time increment 
will be executed.
· Delta Step: This command is used to run the current simulation for a single cycle, which can be 
called a Delta step. A Delta step can be so small that no change in real time is seen.
· Step Into enables the user to single­step through the executable lines of code in the source 
VHDL documents. If any procedures/functions are encountered, stepping will continue into the 
called procedure or function.
· Step Over is similar to Step Into except that if any procedures/functions are encountered, 
stepping will execute the entire procedure/function as a single executable line and will not step 
into it.
· Stop will pause the simulator at its current simulation point. A paused simulation can continue to 
be run with any of the above commands.
· Reset will abort the current simulation, clear any waveforms and reset the time back to 0.
· End terminates the entire simulation session. Ended simulations can not be restarted other than 
by initiating another simulation session. 

1 ­ 56 
Altium Designer Training Module  FPGA Design 

Figure 98. The simulation debugger options in the preferences dialog.

1 ­ 57 
Altium Designer Training Module  FPGA Design 

11.7  Exercise 6 – Create a testbench and simulate MyPWM 
1.  Open the project you created in Exercise 2 and make MyPWM.VHD the active document. 
2.  Select Design » Create VHDL Testbench from the menu.  Update the testbench to be the 
same as the code listed in Figure 99. 

Figure 99. Testbench code for testing MyPWM 

3.  Update the testbench document, top­level entity/configuration and top­level architecture 
fields in the simulation tab of the Project » Project Options dialog. 
4.  Compile the testbench document and rectify any errors. 
5.  Run the simulation by selecting Simulator » Simulate. 
6.  Run the simulator for 2us. 
7.  Observe the waveforms for LEDS[0] and LEDS[1].  Is it what you expect?  Try changing the 
PWM period by changing the value of SW in the testbench.

1 ­ 58 
Altium Designer Training Module  FPGA Design 

12  Review

1 ­ 59 
Designing Systems on FPGAs

1­1 
Document Version 1.2, April 2008 

Software, documentation and related materials: 
Copyright © 2008 Altium Limited. 
All rights reserved. You are permitted to print this document provided that (1) 
the use of such is for personal use only and will not be copied or posted on 
any network computer or broadcast in any media, and (2) no modification of 
the document is made. Unauthorized duplication, in whole or part, of this 
document by any means, mechanical or electronic, including translation into 
another language, except for brief excerpts in published reviews, is prohibited 
without the express written permission of Altium Limited. Unauthorized 
duplication of this work may also be prohibited by local statute. Violators may 
be subject to both criminal and civil penalties, including fines and/or 
imprisonment. 
Altium, Altium Designer, Board Insight, CAMtastic, CircuitStudio, Design 
Explorer, DXP, LiveDesign, NanoBoard, NanoTalk, Nexar, nVisage, P­CAD, 
Protel, SimCode, Situs, TASKING, and Topological Autorouting and their 
respective logos are trademarks or registered trademarks of Altium Limited or 
its subsidiaries. 
Microsoft, Microsoft Windows and Microsoft Access are registered trademarks 
of Microsoft Corporation. OrCAD, OrCAD Capture, OrCAD Layout and 
SPECCTRA are registered trademarks of Cadence Design Systems Inc. 
AutoCAD is a registered trademark of AutoDesk Inc. HP­GL is a registered 
trademark of Hewlett Packard Corporation. PostScript is a registered 
trademark of Adobe Systems, Inc. All other registered or unregistered 
trademarks referenced herein are the property of their respective owners and 
no trademark rights to the same are claimed. 

Module 2

1­2 
1  Designing a System to Display Video ..................................................................1­5 
1.1  The nuts and bolts of capturing video..........................................................1­5 
1.2  The nuts and bolts of Displaying video on a touch screen............................1­6 
1.3  A high level view of our system ...................................................................1­6 
2  Utilizing microprocessor softcores......................................................................2­7 
2.1  How soft is a softcore?................................................................................2­7 
2.2  Using a softcore in an FPGA schematic ......................................................2­8 
2.3  Accessing softcore datasheets....................................................................2­8 
2.4  The TSK3000 Processor .............................................................................2­8 
2.5  Exercise 1 – Placing a softcore onto an FPGA schematic............................2­9 
2.6  Configuring the TSK3000 processor............................................................2­9 
2.7  Exercise 2 – Configuring the TSK3000A Processor ...................................2­11 
3  Wishbone Interconnection Architecture ............................................................3­12 
3.1  Wishbone compatible cores ......................................................................3­12 
3.2  Wishbone interface signal descriptions......................................................3­13 
3.3  Pin naming conventions for wishbone signal pins......................................3­15 
4  Placing the FPGA Peripherals ............................................................................4­17 
4.1  Exercise 3 – Placing the peripherals .........................................................4­17 
5  Bus Interconnectivity and Arbitration ................................................................5­20 
5.1  Wishbone Interconnect Component WB_INTERCON................................5­20 
5.2  Configuring the Wishbone Interconnect component...................................5­21 
5.3  Exercise 4 – Connecting our Peripherals...................................................5­24 
5.4  Managing memory access ........................................................................5­25 
5.5  Arbitration of multiple masters sharing a single slave.................................5­25 
5.6  Wishbone Dual­ and Multi­ Master devices................................................5­26 
5.7  Configuring the wishbone multi­ master component...................................5­27 
5.8  Exercise 5 – Defining our Multi Master Components..................................5­30 
6  Interfacing to External Memory ..........................................................................6­31 
6.1  Configuring the SRAM Controller ..............................................................6­31 
6.2  The Shared Memory Controller .................................................................6­33 
6.3  Configuring the Shared Memory Controller................................................6­34 
6.4  Exercise 6 – Placing and configuring memory controllers ..........................6­36 
6.5  Exercise 7 – Multiple memories as slaves .................................................6­37 
6.6  Exercise 8 – Placing the Port Plug In Components....................................6­38 
6.7  Exercise 10 – Wiring Up Your FPGA Design .............................................6­40 
7  Configuring Processor Memory .........................................................................7­42 
7.1  Dividing the processor memory .................................................................7­43 
7.2  Exercise 11 – Configuring the processor memory......................................7­45 
7.3  Configuring processor peripherals.............................................................7­46 
7.4  Exercise 12 – Specifying processor peripherals.........................................7­47 
8  Finalizing the Design, Compiling and Resolving Errors....................................8­48 
9  Creating Embedded Systems on FPGAs ...........................................................9­49 
9.1  Exercise 13 – Editor Basics.......................................................................9­49 
9.2  The TASKING tool chain...........................................................................9­53 
9.3  The Build flow ...........................................................................................9­53 
9.4  Targeting the Project.................................................................................9­54 
9.5  Project options..........................................................................................9­54 
9.6  Attaching an embedded project to an FPGA project ..................................9­66 
9.7  Exercise 13 – Linking projects...................................................................9­68 
9.8  Exercise 14 – Building our design .............................................................9­68 
9.9  Exercise 15 – Updating our software Live..................................................9­70 
10  Updating the Design to Display Video ............................................................. 10­71 
10.1  Defining Sections.................................................................................... 10­71 
10.2  Exercise 16 – Updating our software Live................................................ 10­72

1­3 
10.3  Exercise 17 – Updating our Software to Capture Video ........................... 10­73 
10.4  Utilizing the Virtual Instruments ............................................................... 10­74 
10.5  Using instruments to control our design................................................... 10­74 
10.6  Exercise 18 – Updating the Wishbone Port IO......................................... 10­75 
10.7  Exercise 19 – Adding the Virtual Instruments .......................................... 10­76 
10.8  Exercise 20 ­ Rebuilding the project with instruments .............................. 10­78 
10.9  Updating our embedded project to use the instruments ........................... 10­78 
10.10  Exercise 21 – Adding Additional Source Files.......................................... 10­78 
10.11  Exercise 22 – Updating main.c................................................................ 10­78 
10.12  Exercise 23 – Controlling our design with instruments ............................. 10­79 
11  Real­time Debugging of a Processor ............................................................... 11­81 
11.1  On­Chip Debugging ................................................................................ 11­81 
11.2  A word about simulation.......................................................................... 11­81 
11.3  Embedded control panels........................................................................ 11­83 
11.4  Instrument Rack – Nexus Debugger........................................................ 11­89 
12  C to Hardware.................................................................................................... 12­92 
12.1  What are the benefits of the C­to­Hardware Compiler?............................ 12­92 
12.2  Using the CHC Compiler......................................................................... 12­92 
12.3  Implementing C to Hardware in our Design ............................................. 12­93 
12.4  Exercise 24 – Making Room for C to Hardware ....................................... 12­93 
12.5  Exercise 25 – Adding the Application Specific Processor......................... 12­94 
12.6  Exercise 26 – Giving the ASP Access to Memory (part 1)........................ 12­95 
12.7  Exercise 27 – Giving the ASP Access to Memory (part 2)........................ 12­97 
12.8  Configuring the ASP ............................................................................. 12­101 
12.9  Exercise 28 – Accelerating our performance with ASP .......................... 12­103 
13  OpenBus.......................................................................................................... 13­106 
13.1  Creating an OpenBus version of our design .......................................... 13­106 
13.2  Exercise 29 – Beginning an FPGA Project Using    OpenBus ................ 13­106 
13.3  OpenBus Devices ................................................................................. 13­107 
13.4  Exercise 30 – Placing Open Bus Components (part 1) .......................... 13­107 
13.5  Exercise 31 – Using an Interconnect ..................................................... 13­111 
13.6  Exercise 32 – Linking OpenBus Ports ................................................... 13­114 
13.7  Exercise 33 – Configuring our processor under open bus...................... 13­115 
13.8  Exercise 34 – Configuring the GPIO Component................................... 13­115 
13.9  Exercise 35 – Finalizing the Interconnect Component ........................... 13­116 
13.10  Defining the Memory Side of our System............................................... 13­117 
13.11  Exercise 36 – Adding the Remaining Components ................................ 13­117 
13.12  Exercise 37 – Completing the Connectivity............................................ 13­118 
13.13  Exercise 38 – Configuring the SRAM Controllers................................... 13­118 
13.14  Exercise 39 – Configuring the Arbiters .................................................. 13­120 
13.15  Exercise 40 – Configuring the Interconnects.......................................... 13­121 
13.16  Finalizing the OpenBus Portion of the Design........................................ 13­121 
13.17  Exercise 41 – Configuring the Processor Memory ................................. 13­122 
13.18  Exercise 42 ­ Creating a sheet symbol from an  OpenBus Document .... 13­123 
13.19  Exercise 43 – Linking an Embedded Project to an OpenBus Design...... 13­124 
13.20  Exercise 44 – Processing an OpenBus Design...................................... 13­125 
14  Review ............................................................................................................. 14­126

1­4 
1  Designing a System to Display Video 
This next section of the course is designed to take you through the process of developing a 
complete soft processor based system on an FPGA.  To accomplish this, we will follow a 
single design through a variety of different stages and different capture methods.  The design 
we’ve chosen is a simple video display system capable of capturing composite video and 
displaying the video on a touch screen, with options to scale and rotate the image. 
Central to our design will be the TSK3000A, a derivative of the TSK3000 family of soft 
microprocessors supplied with Altium Designer.  Supporting the TSK3000A will be a host of 
peripherals that will supply the means with which to both capture and display our video on the 
touch screen located on the Desktop NanoBoard. 

1.1  The nuts and bolts of capturing video 
The Desktop NanoBoard’s peripheral board PB01 supports the connection of external PAL or 
NTSC analog video signals.  Both Composite Video and S­Video inputs are supported.
· Connection of a Composite Video signal is made through two RCA phono jacks, 
designated J5 and J6, which cater for the Luma (luminance or intensity) and Chroma 
(chrominance or color) components of the signal respectively. 

The analog video input is converted into an 8­bit digital YCbCr 4:2:2 component video through 
the use of a TVP5150AM1 video decoder device from Texas Instruments. 

The decoder provides a 9­bit ADC, with sampling carried out in accordance with the ITU­R 
BT.601 recommendation.  This recommendation defines the scheme for encoding interlaced 
analog video signals – for both 625 and 525 line systems – in digital form. 

The converted digital video stream can be output in one of two formats:
· 8­bit ITU­R BT.656 interface with embedded synchronization
· 8­bit 4:2:2 YCbCr, with discrete synchronization signals 
By default the TVP5150AM1 is configured to output digital video in the ITU­R BT.656 format 
and this is the format expected by a BT656 Controller used within and FPGA design.

1­5 
In our design, we will use the BT656 Controller core supplied with Altium Designer to fetch 
the video from the video decoder and supply that to the rest of our system. 

The BT656 Controller takes as its inputs from the TVP5150AM1:
· VIDIN_DATA[7..0] – the ITU­R BT.656­compliant video stream
· VIDIN_PCLK – the pixel clock, fixed at 27 MHz and used to clock the output video 
data stream
· VIDIN_INTERQ_GPLC – used to indicate the vertical blanking interval of the video 
data stream 

The video decoder is controlled by a processor within the FPGA design over the I2C bus. 
The decoder (an I2C slave) is controlled through an intermediate I2C controller (the I2C 
master, also resident within the FPGA design). 

1.2  The nuts and bolts of Displaying video on a touch screen 
The Desktop NanoBoard provides high quality color display through a Hitachi 
TX09D50VM1CAA TFT (Thin Film Transistor) LCD panel.  The panel also features an analog 
resistive touch screen.  From a user perspective you can either output straightforward 
graphics to the panel, or provide a more sophisticated level of interaction involving input to 
your FPGA design from the touch screen. 

The 3.5” panel features a Transmissive Color TFT LCD, with a resolution of 240(W) by 
340(H).  The display is based on an active matrix and backlight for the panels is provided 
through 6 LEDs.  The panel is fixed to use 16bpp (bits per pixel) display, with bit 0 from both 
Red and Blue intensity inputs tied to GND.  This results in a total of 65536 colors being 
available for display. 

In our design, we will use the WB_VGA Configurable Wishbone Display Driver supplied 
with Altium Designer to fetch 16bpp­formatted data from external memory, process it, and 
display it on the connected TFT LCD panel.  All of the control signals are generated in­core, 
using an integrated TFT Timing Controller unit. 

1.3  A high level view of our system 
It helps to have a high­level understanding of how our system will go together before getting 
started.  Below is a block diagram that explains the flow of data in to and out of our system. 
Analog Video Input 

ADC 

TVP5150AM1  BT656 Controller  TSK3000  VGA TFT Controller 

Figure 1. Simplified flow diagram of our system. 

Figure 1 shows a simplified flow diagram of our system.  On the left hand side of the diagram 
you can see the analog video input.  This is converted to digital by the TVP5150AM1 and 
output as BT656 to the FPGA­based BT656 decoder.  This will then be processed by the 
TSK3000 and output to the touch screen display using an FPGA­based VGA controller.

1­6 
2  Utilizing microprocessor softcores 
In this section we will begin to explore utilizing soft microprocessor cores on FPGAs. 

2.1  How soft is a softcore? 
Altium Designer comes bundled with a number of pre­verified, pre­synthesized 
microprocessor softcores that can be incorporated into an FPGA project.  These processors 
are labeled as soft because they are implemented as a downloadable core (utilizing 
resources on the FPGA) that runs from an FPGA device rather than as a hard physical 
microprocessor in its own distinct package. 

Figure 2. Pictorial representation of a softcore loaded onto an FPGA device. 

One of the fundamental differences between FPGA­based microprocessor cores (such as 
those bundled with Altium Designer) and hard processors is the relationship of the peripherals 
to the processor itself.  In traditional hard processors, a set of standard peripherals will come 
“on­chip” and are fixed (i.e. cannot be changed).  An example might be an 8051 with an on­ 
chip High Speed USB interface.  FPGA­based processors on the other hand, generally 
include only the CPU enabling the engineer to pack whatever peripherals might be required 
‘around’ the processor.  This is central to the increased flexibility / scalability of FPGA­based 
“systems”.  Systems can be modified in the soft domain to add and remove peripherals as a 
design changes, allowing more flexibility at the design stage to make real­time modifications 
to a system thus not requiring the engineer to “lock­in” the hardware up front.

2­7 
2.2  Using a softcore in an FPGA schematic 
Building an FPGA project that incorporates a softcore is no different from building any other 
FPGA project; you simply select components from a library and place them onto your 
schematic.  The FPGA softcores can be accessed from the integrated library FPGA 
Processors.IntLib 

Figure 3. FPGA Processors.IntLib library contents with popup Help 

2.3  Accessing softcore datasheets 
Detailed data sheets can be accessed for each device by highlighting the device and 
selecting the F1 key or by right­clicking the device in the Libraries panel and selecting Show 
Help for <Device Name> as seen in Figure 3. 

2.4  The TSK3000 Processor 
Central to our design is the TSK3000A core.  The TSK3000A is a configurable 32­bit, 
Wishbone­compatible, RISC processor core. Most instructions are 32­bits wide and execute 
in a single clock cycle. In addition to fast register access, the TSK3000A features a user 
definable (from 1K Bytes up to 1M Bytes) amount of zero­wait state block RAM, with true 
dual­port access.

2­8 
The TSK3000A also features:
· FPGA device­independent implementation
· 5­stage pipelined RISC processor
· 32x32­ to 64­bit hardware multiplier, signed and unsigned
· 32x32­bit hardware divider
· 32­bit single­cycle barrel shifter
· 32 input interrupts, individually configurable to be level or edge sensitive and used in 
one of two modes: 
­  Standard Mode ­ all interrupts jump to the same, configurable base vector 
­  Vectored Mode ­ providing 32 vectored priority interrupts, each jumping to a 
separate interrupt vector
· Internal Harvard architecture with simplified external memory access
· 4GByte address space
· Wishbone I/O and memory ports for simplified peripheral connection
· Full Viper­based software development tool chain – C compiler/assembler/source­ 
level debugger/profiler
· C­code compatible with other Altium Designer 8­bit and 32­bit Wishbone­compliant 
processor cores, for easy design migration 

2.5  Exercise 1 – Placing a softcore onto an FPGA schematic 
In this exercise we will create a new FPGA project and add the TSK3000A to a new, blank 
schematic document. 
1.  Create a new FPGA project and a new schematic sheet 
2.  Adjust the sheet to C­size within the Document Options dialog located under 
Design»Document Options or by double clicking in the border area around the 
outside of the schematic document. 
3.  Save the FPGA project using File»Save Project As… and you will be prompted to 
save both the schematic and the FPGA project.  Name the files 
CHC_Image_Rotation.SchDoc and CHC_Image_Rotation.PrjFpg respectively. 
4.  Select the TSK3000A processor from the FPGA Processors.IntLib library and place it 
onto the schematic. 
5.  Annotate the component U2 and save your work. 

2.6  Configuring the TSK3000 processor 
The Configure (32­bit Processors) dialog (Figure 4) is accessible by right­clicking the 
processor in the schematic and selecting Configure... or alternatively by selecting the 
Configure button in the component properties dialog.

2­9 
Figure 4. Processor configuration dialog 

Several options are available when configuring the processor:
· Internal Processor Memory 
This is a user configurable feature of the TSK3000A.  Utilizing dual­port FPGA Block 
RAM, this area generally contains the boot portion of your application as well as 
interrupt and exception handlers. 
This memory is generally the fastest and you will want to consider placing any speed­ 
critical parts of your application in this memory space.  This memory is however 
limited to the amount of Dual Port Block RAM available in the FPGA and thus the 
amount you specify needs to be balanced for the device selected.
· The Multiply / Divide Unit (MDU) 
Fundamentally there are two approaches to managing multiply / divide instructions, 
one being to implement them in hardware using FPGA resources to create the 
multiply (MULT, MULTU) and divide (DIV, DIVU) hardware instructions, or 
alternatively implementing them in software such that these instructions are emulated 
by the C­Compiler. 
This is a tradeoff of speed versus size.  The Hardware MDU will be faster as these 
instructions have dedicated hardware resources, however it will consume FPGA 
resources and thus the space available in the FPGA will be reduced.
· On­Chip Debug System 
The TSK3000 includes an optional on­chip debugging (OCD) system.  The OCD 
system can be used to debug a processor as it executes in system, in real time.  This 
includes options to: 
o  Reset, Go, Halt processor control 
o  Single or multi­step debugging 
o  Read­write access for internal processor registers 
o  Read­write access for memory and I/O space 
o  Unlimited software breakpoints 
The on chip­debugging system can be removed at any time which will then free up 
the FPGA resources it requires.  No changes will be required in the source embedded

2­10 
application when switching between OCD and non­OCD versions of the 
microprocessor.
· Breakpoints on Reset 
The TSK3000A has the feature to enable the application to run to a breakpoint after a 
hard reset (RST_I pin goes high).  This option is user configurable and can be 
selected depending on the needs of the target application. 

2.7  Exercise 2 – Configuring the TSK3000A Processor 
Having placed the TSK3000A in our design, we now need to configure it for our application. 

1.  Right­click the TSK3000A in the schematic and select Configure U2 (TSK3000A). 


This will launch the Configure (32­bit Processors) dialog. 
2.  Set the Internal Processor Memory option to 32K Bytes (8K x 32­Bit Words) 
3.  Set the Multiply/Divide Unit (MDU) option to Hardware MDU 
4.  Set the On­Chip Debug System  option to Include JTAG­Based On­Chip Debug 
System 
6.  Set the Breakpoints on Reset option to Disable Breakpoints on Hard Reset

2­11 
3  Wishbone Interconnection Architecture 
Altium Designer makes extensive use of the Wishbone Interconnection Architecture.  A copy 
of the Wishbone standard is available from www.opencores.org or located within the help 
system in Altium Designer.  Simply stated, Wishbone is an open­source standard that 
specifies the interface to IP cores, thus making it easier to connect blocks of Intellectual 
Property cores together in an FPGA / ASIC design.  The intent being that if all IP blocks have 
a standard interface, blocks of IP will then be more easily reusable, more easily 
interchangeable, and the time spent negotiating transactions between cores will be reduced 
or eliminated. 

What Wishbone Is Not 
Wishbone does not specify the behavior or architecture of the IP itself.  Instead, Wishbone is 
intended to be “General Purpose” with its emphasis on data exchange and not a core’s 
function. 

Like discrete microprocessors which include an address bus, data bus, and handshaking 
lines, the Wishbone Interconnection Architecture defines the signals required to interface IP 
blocks to one another and how they operate.  Wishbone does not imply the electrical 
characteristics of the interconnections but is intentionally focused on the logical 
implementation of a common mechanism for the interaction between IP. 

3.1  Wishbone compatible cores 
With the TSK3000A configured, the next stage in our project is to specify the peripheral cores 
required and connect them to the processor.  There is a range of Wishbone compatible 
peripheral cores provided in the FPGA Peripherals.IntLib library and it’s this Wishbone 
compatibility that makes the interconnection of these components fast and easy. 

For example, in the figure below, notice the uniformity of the various interfaces of these two 
components. 

BT656 Controller  TSK3000A 32­Bit RISC Processor 
VID_DATA[7..0]  WBS_STB_I  IO_STB_O  ME_STB_O 
PCLK  WBS_CYC_I  IO_CYC_O  ME_CYC_O 
VBLK  WBS_ACK_O  IO_ACK_I  ME_ACK_I 
WBS_ADR_I[2..0]  IO_ADR_O[23..0]  ME_ADR_O[31..0] 
WBS_DAT_O[31..0]  IO_DAT_I[31..0]  ME_DAT_I[31..0] 
WBS_DAT_I[31..0]  IO_DAT_O[31..0]  ME_DAT_O[31..0] 
WBS_SEL_I[3..0]  IO_SEL_O[3..0]  ME_SEL_O[3..0] 
WBS_WE_I  IO_WE_O  ME_WE_O 
CLK_I  IO_CLK_O  ME_CLK_O 
RST_I  IO_RST_O  ME_RST_O 
INT_O[1..0]  INT_I[31..0] 

Current Configuration 
WBM_STB_O 
WBM_CYC_O  MDU              : Installed 
WBM_ACK_I  Debug Hardware   : Installed 
WBM_ADR_O[31..0]  Internal Memory  : 32 KB 

WBM_DAT_O[31..0] 
WBM_SEL_O[3..0] 
CLK_I 
WBM_WE_O 
RST_I 
BT656  TSK3000A 

Figure 5. A look at the Wishbone signal pins on schematic symbols

3­12 
The pin names are quite similar as they are derived from the Wishbone standard and their 
names reference the Wishbone interface signal names.   To further simplify the interfacing of 
IP ‘components’ to one another, Wishbone requires that all Wishbone signals are active high. 
This makes representing the signals in schematic capture tools easier as it eliminates the 
challenge of uniformly representing active low logic (graphically) in a schematic design (i.e. 
over bar, hash marks, slashes, etc.) 

3.2  Wishbone interface signal descriptions 
The wishbone signals can be grouped as either Master, Slave, common to both Slave and 
Master, or SYSCON module signals (a module is SYSCON if it drives the system clock 
CLK_O and the reset RST_O signals).  The following table is a list of Wishbone signals used 
in Altium Designer.  For a complete list of Wishbone signals and signal descriptions, refer to 
the Wishbone specification found at www.opencores.org or in the help system. 
Wishbone SYSCON Signals 

Signal Name  Signal Description 
CLK_O  External (system) clock signal (identical to 
CLK_I) made available for connecting to the 
CLK_I input of a slave device 
RST_O  Reset signal available to connect to a slave 
device 

Wishbone Common Signals (Master and Slave) 

Signal Name  Signal Description 
CLK_I  External (system) clock signal 
DAT_I[x..y]  Data input array from an external device such as 
memory.  Maximum width 64 bits. 
DAT_O[x..y]  Data output array to an external device such as 
memory.  Maximum width 64 bits. 
RST_I[x..y]  External (system) reset signal 

Wishbone Master Signals 

Signal Name  Signal Description 

ACK_I  Standard Wishbone acknowledgement signal 
used to acknowledge the completion of a 
requested action. 

ADR_O[x..y]  Standard Wishbone address bus, used to select 
an address in a connected Wishbone slave 
device for writing to/reading from. 

CYC_O  Cycle signal. When asserted, indicates the start 
of a valid Wishbone bus cycle. This signal 
remains asserted until the end of the bus cycle, 
where such a cycle can include multiple data 
transfers 

ERR_I  Error input signal.  Used to indicate the abnormal 
termination of a cycle.

3­13 
RTY_I  Retry input signal. Informs the Wishbone Master 
interface that the Wishbone Slave is not ready to 
send or receive data at this time and the data 
exchange should be retried. 

SEL_O[x..y]  Select output signal.  Used to indicate where 
data is placed on the DAT_O line during a Write 
cycle and from where data is accessed on the 
DAT_I line during a Read cycle.  Data ports have 
both a width and a granularity.  For example a 
32­bit wide data port with 8­bit granularity would 
allow data transfers of 8­ 16­ or 32­bits.  The 
Select bits allow targeting of each of the bit 
ranges with 0 corresponding to the lowest range 
and incrementing from there. 

STB_O  Strobe signal.  When asserted, indicates the 
start of a valid Wishbone data transfer cycle. 

WE_O  Write enable signal.  Used to indicate whether 
the local bus is a Read or Write cycle. 
0 = Read 
1 = Write 

Wishbone Slave Signals 

Signal Name  Signal Description 

ACK_O  Standard Wishbone device acknowledgement 
signal. When this signal goes high, the 
Wishbone Slave has finished execution of the 
requested action and the current bus cycle is 
terminated. 

ADR_I[x..y]  Standard Wishbone address bus, used to select 
an internal register of the Wishbone slave device 
for writing to/reading from. 

CYC_I  Cycle signal. When asserted, indicates the start 
of a valid Wishbone cycle 

ERR_O  Error output signal.  Used to indicate the 
abnormal termination of a cycle. 

RTY_O  Retry output signal. Informs the Wishbone 
Master interface that the Wishbone Slave is not 
ready to send or receive data at this time and the 
data exchange should be retried. 

SEL_I[x..y]  Select input signal.  Used to indicate where data 
is placed on the DAT_O line during a Read cycle 
and from where data is accessed on the DAT_I 
line during a Write cycle.  Data ports have both a 
width and a granularity.  For example a 32­bit 
wide data port with 8­bit granularity would allow 
data transfers of 8­ 16­ or 32­bits.  The Select 
bits allow targeting of each of the bit ranges with 
0 corresponding to the lowest range and 
incrementing from there.

3­14 
STB_I  Strobe signal. When asserted, indicates the start 
of a valid Wishbone data transfer cycle. 

WE_I  Write enable signal. Used to indicate whether the 
current local bus cycle is a Read or Write cycle. 
0 = Read 
1 = Write 

3.3  Pin naming conventions for wishbone signal pins 
Altium Designer utilizes several prefixes when naming schematic symbol pins that are a part 
of the wishbone interface.  These prefixes are intended to make the connection of Wishbone 
compatible devices easier and more intuitive.  The following table provides a list of common 
prefixes used in Altium Designer, though not a part of the Wishbone Interface standard. 
Prefixes will be applied following the convention: 

<prefix>_<wishbone signal name> 

So for example, the prefix ME indicates the interface to the memory bus on the host 
processor, thus the pin name ME_STB_O would indicate the Strobe Signal output on the 
memory interface of a device such as TSK3000A. 

Common Prefixes Used in Wishbone Interface Signal Pin Names 

Interface Prefix  Prefix Description 

ME  Processor interface to the memory bus of the 
host processor 

me  Peripheral interface to the memory bus of the 
host processor 

IO  Processor interface to the IO bus of the host 
processor 

io  Peripheral interface to the IO bus of the host 
processor 

WBM  Wishbone Master interface on devices having 
both Master and Slave interfaces (e.g. BT656) 
WBS  Wishbone Slave Interface on devices having 
both Master and Slave interfaces (e.g. BT656)

3­15 
Common Prefixes Used in Wishbone Interface Signal Pin Names (cont.) 

Interface Prefix  Prefix Description 

m<number>_  Indicates a Wishbone Master interface to a 
Wishbone Interconnect or Wishbone Multi 
Master device.   Wishbone Interconnect devices 
are restricted to a single master (typically the 
host processor), thus the Master interface name 
will always be prefixed by m0_.  Wishbone Multi 
Master devices allow the master interfaces to be 
renamed thus m1_, m2_, m3_ might be renamed 
to MCU_, ASP_, VID_ in the device’s 
configuration dialog. 

s<number>_  Indicates a wishbone slave interface to a 
wishbone interconnect device.  The <number> 
attribute uniquely identifies the various interfaces 
when connecting more than one slave peripheral 
to a given master. For example S0, S1, S2, etc. 
would all contain a complete wishbone interface 
signals for slave devices 1, 2, & 3 respectively.

3­16 
4  Placing the FPGA Peripherals 
To complete the FPGA portion of our design, several peripherals are required to round out the 
overall system.  As our application will capture video and display that video on a touch 
screen, it is easy to assume that we’ll need at a minimum a video capture controller, a video 
display driver, and some memory both for the processor, as well as for the capture and 
display devices. 

4.1  Exercise 3 – Placing the peripherals 
In order to complete this task you will need to use the following components from their 
respective libraries: 

Component  Library  Name In Library  Ref Des 


U5 
FPGA Peripherals.IntLib  BT656  U5 
BT656 Controller 
VID_DATA[7..0]  WBS_STB_I 
PCLK  WBS_CYC_I 
VBLK  WBS_ACK_O 
WBS_ADR_I[2..0] 
WBS_DAT_O[31..0] 
WBS_DAT_I[31..0] 
WBS_SEL_I[3..0] 
WBS_WE_I 
CLK_I 
RST_I 
INT_O[1..0] 

WBM_STB_O 
WBM_CYC_O 
WBM_ACK_I 
WBM_ADR_O[31..0] 

WBM_DAT_O[31..0] 
WBM_SEL_O[3..0] 
WBM_WE_O 
BT656 

U7 
FPGA Peripherals.IntLib  I2CM_W  U7 
I2C Master Wishbone 
SDATA_EN  STB_I 
CYC_I 
SDATAO  ACK_O 
ADR_I[2..0] 
SDATAI  DAT_O[7..0] 
DAT_I[7..0] 
SCLK_EN 
WE_I 
SCLKO  CLK_I 
RST_I 
SCLKI  INT_O 
I2CM_W 

U17 
FPGA Peripherals.IntLib  WB_VGA  U17
Wishbone Display Driver 

TFT_RED[4..0]  io_STB_I 
TFT_GREEN[5..0]  io_CYC_I 
TFT_BLUE[4..0]  io_ACK_O 
TFT_CL[3..1]  io_ADR_I[11..0] 
TFT_DISP_ON  io_DAT_O[31..0] 
TFT_M  io_DAT_I[31..0] 
TFT_POL  io_SEL_I[3..0] 
TFT_STH  io_WE_I 
TFT_STV  io_CLK_I 
io_RST_I 
io_INT_O[2..0] 

me_STB_O 
me_CYC_O 
me_ACK_I 
me_ADR_O[19..0] 
me_DAT_I[31..0] 

me_SEL_O[3..0] 
me_WE_O 

WB_VGA 

4­17 
Component  Library  Name In Library  Ref Des 

U9 
FPGA Generic.IntLib  IOBUF  U9, U10 

U10 

U14 
FPGA Peripherals.IntLib  WB_PRTIO  U14
Port Wishbone 
PAO[7..0]  STB_I 
CYC_I 
ACK_O 

DAT_I[7..0] 

WE_I 
CLK_I 
RST_I 

WB_PRTIO 

1.  Place the BT656 Controller core BT656 – this will be used to capture the digital video 
signal from the video decoder.  Designate this component U5 
2.  Select and place the I2C Master Wishbone core I2CM_W.  This will provide the 
intermediate I2C controller to control the video decoder.  Designate this part U7. 
3.  Select and place the configurable Wishbone Display Driver WB_VGA.   This will fetch the 
16bpp­formatted data from external memory and display it on the TFT panel. 
Designate this part U17. 
4.  Right­click the Wishbone Display Driver WB_VGA and select Configure.  Configure the 
component to match the figure below: 

5.  We will also require two I/O buffers for the I2C interface from the I2C Master Controller 
core to the SDA and SCL signals on the video decoder.  Select the FPGA 
Generic.IntLib  from the Libraries panel and place two IOBUF components. 
Designate them U9 and U10. 
6.  Though not a required component of our system, we will also make use of a 
Configurable Wishbone Port WB_PRTIO as a means to test our code.  Designate this 
component U14. 
7.  Align all of your peripheral components along the left side of your processor as seen in 
Figure 6. 

4­18 
Figure 6. Placement of peripherals in schematic

4­19 
5  Bus Interconnectivity and Arbitration 
Unlike off­the­shelf microprocessors which have their peripherals fixed at the time of 
manufacture, FPGA­based platforms have total flexibility.  The choice in the number and type 
of peripherals is totally configurable and can be tailored to the specific needs of the 
application.  This also adds a layer of complexity however, that until Altium Designer and the 
advent of interconnect architectures such as wishbone was difficult to manage. 

Specifically, there exists the problem of how the peripherals interact with the processor when 
more than one peripheral needs access to a shared peripheral bus.  This process historically 
was handled with glue logic to decode the address of the peripheral with which the processor 
was intended to communicate. 

Further adding the complexity are devices that require direct memory access (DMA) and the 
management of multiple devices which again need share a single bus when interfacing to 
memory.  Altium Designer addresses both of these issues with the Configurable Wishbone 
Interconnect, WB_INTERCON, and Configurable Wishbone Dual Master WB_DUALMASTER 
and Multi Master WB_MULTIMASTER components. 

5.1  Wishbone Interconnect Component WB_INTERCON 
The WB_INTERCON peripheral device provides a means of accessing one or more 
Wishbone­compliant slave devices over a single Wishbone interface.   Connecting directly to 
either the External Memory or Peripheral I/O Interfaces of a processor, the device facilitates 
communication with physical memory devices or I/O peripherals, respectively. 

The WB_INTERCON features:
· Complete configurability on the schematic sheet
· 1­to­n multiplexing (! Wishbone Master interface, multiple Wishbone Slave interfaces)
· Ability to control decoder address width
· Automatic hardware decoder generation
· Ability to define specific mapping into Processor address space
· 8­, 16­, and 32­bit Slave peripheral support
· Configurable addressing modes – allowing a slave device to be either byte or “word” 
addressed 
WB_INTERCON 

Wishbone Interconnect 
m0_STB_I  s0_STB_O 
m0_CYC_I  s0_CYC_O 
m0_ACK_O  s0_ACK_I 
m0_ADR_I[31..0]  s0_ADR_O[19..0] 
m0_DAT_O[31..0]  s0_DAT_I[31..0] 
m0_DAT_I[31..0]  s0_DAT_O[31..0] 
m0_SEL_I[3..0]  s0_SEL_O[3..0] 
m0_WE_I  s0_WE_O 
m0_CLK_I  s0_CLK_O 
m0_RST_I  s0_RST_O 

s1_STB_O 
s1_CYC_O 
s1_ACK_I 
s1_ADR_O[19..0] 
s1_DAT_I[31..0] 
s1_DAT_O[31..0] 
s1_SEL_O[3..0] 
s1_WE_O 
s1_CLK_O 
s1_RST_O 

Figure 7. Wishbone Interconnect Component

5­20 
5.2  Configuring the Wishbone Interconnect component 
The Wishbone Interconnect component can be configured by right­clicking the component in 
schematic and selecting Configure <RefDes> (WB_INTERCON) or by launching the 
component properties dialog and hitting the configure button at the lower left. 

Figure 8. Wishbone Interconnect Component configuration dialog 

In this dialog are options to Add, Remove, and Edit the banks of Wishbone Slave device 
interfaces, as well as options to Move Up and Move Down, physically reordering the location 
of the banks with respect to the schematic symbol. 

The Unused Interrupts drop­down is used to control the behavior of any unused interrupts 
on the host processor.  The available options are:

· Add SPARE INT input pin – use this option to make the unused interrupt signals 
available as an additional input pin. Interrupts from additional circuitry in the design 
can be wired into this pin.
· Connect to GND – use this option to internally connect all unused interrupts to 
GND. The interrupt output signal pattern that is sent to the Wishbone Master device 
will contain ‘0’ for each of these unused interrupts.
· No Interrupt output pin – use this option to effectively disable marshalling of 
interrupts to the processor. Any configured interrupt input pins for slave devices will 
be removed from the symbol, as well as the spare interrupts pin (where applicable) 
and the output pin to the Wishbone Master. 

The Master Address Size drop­down is used to specify the address size depending on the 
type of slave peripheral(s) being connected.  The 32­Bit(Memory) option is used when 
connecting to slave memory devices. If using the device to connect to slave peripheral I/O 
devices, ensure that this option is set to 24­Bit(Peripheral I/O).

5­21 
Again, the order in which the devices appear in this dialog will determine the order in which 
the Wishbone Interface pins will appear on the schematic symbol, from top to bottom.  Using 
Move Up and Move Down in the Configure U1 (Wishbone Intercon) dialog will reorder the 
groups of signals as they appear in schematic. 

The Add Device option is used to add a new wishbone slave device.  This will launch the 
Device Properties dialog that appears in figure 9. 

Figure 9. Adding a device to the wishbone interconnect component 

The following table describes the various properties that can be defined for a wishbone slave 
interface. 

Interface Property  Description 
Name  Then name is a user­definable field and should 
meaningful when listed alongside other connected 
devices. 
Type  Used to specify the type of Wishbone Slave Device is 
being connected.

5­22 
Interface Property  Description 
Address Bus Mode  Select either Word or Byte addressing. In byte 
addressing mode, all of the lower address lines are 
passed to the slave, regardless of the resolution of its 
data bus. The slave device will handle “byte­to­word” 
management.  In word addressing mode, the mapping 
of the address lines are passed to the slave device’s 
data bus width:
· 32­bit wide devices – the two lowest address bits 
are not connected to the slave device. ADR_I(2) 
from the master is mapped to ADR_O(0) of the 
slave, providing sequential word addresses (or 
addresses at every 4 bytes). Registers/address 
locations in such devices can be read and written 
using the LW and SW 32­bit load/store instructions
· 16­bit wide devices – the lowest address bit is not 
connected to the slave device. ADR_I(1) from the 
master is mapped to ADR_O(0) of the slave, 
providing sequential half­word addresses (or 
addresses at every 2 bytes). Registers/address 
locations in such devices can be read and written 
using the LHU and SH 16­bit load/store instructions
· 8­bit wide devices – all address bits are 
connected through to the slave device. ADR_I(0) 
from the master is mapped to ADR_O(0) of the 
slave, providing sequential byte addresses. This is 
identical to byte addressing. Registers/address 
locations in such devices can be read and written 
using the LBU and SB 8­bit load/store instructions. 

Address Base  Used to specify a decoder base address for a Slave 
device.  A portion of this address – specified by the 
Decode Addressing value – will be compared against 
the corresponding bits of the incoming m0_ADR_I 
signal to determine whether the slave is being 
addressed or by the processor or not. 

Decode Addressing  Defines the decoder address width.  This value 
determines the number of upper address bits on the 
m0_ADR_I line that are decoded to select the correct 
slave device.  There in turn this value also determines 
the number of slave devices that can be connected to 
the interconnect device.

5­23 
Interface Property  Description 
Address Bus Width  Used to specify the number of address bits 
required to drive the connected slave device. 
For slave memory devices – which are 
connected via the Memory Controller device – 
you need to set the address bus to the same 
width as the ADR_I line for the Memory 
Controller. The Memory Controller will 
automatically size its ADR_I line according to the 
size of the physical memory it is connecting to. 
For slave peripheral devices, you need to set the 
address bus to the same width as the ADR_I line 
for the peripheral. 

Data Bus Width  Used to specify the resolution of the data bus for 
the slave device.  8­bit, 16­bit and 32­bit data 
bus widths are supported. 

Used Interrupts  Used to select which interrupt(s) to use for the 
slave device.  For each interrupt line, you can 
also define its type – whether it is level­sensitive 
or edge­triggered – as well as its polarity. 
Interrupts generated by Altium Designer 
Wishbone peripheral devices have positive 
polarity and are level­sensitive, and this is 
therefore the default setting.  You can also 
specify the required interrupt pins to be used by 
directly typing within the available text field – in 
the Device Properties dialog. 
Any defined interrupts will appear as part of the 
overall 32­bit interrupt input bus sent to the 
Wishbone Master (e.g. a 32­bit host processor). 
Graphical Attributes  Alters the amount of blank space inserted after a 
bank of pins.  An increase of +1 unit = +10 
schematic grid units or +100 mil spacing (1:1) 

5.3  Exercise 4 – Connecting our Peripherals 
Connecting the host processor to the various peripherals we’ve placed is accomplished using 
the Configurable Wishbone Interconnect component.  In this exercise we will see how to 
configure this component for our design. 
1.  From the libraries panel, select the FPGA Peripherals.IntLib  and place the 
Configurable Wishbone Interconnect component WB_INTERCON  between the left side 
of the host processor and the right side of the peripherals already placed.  Designate 
this component U1. 
2.  Notice that currently this device has only one set of Wishbone signal pins, prefixed m0. 
The m0 prefix indicates the Master Interface and should be facing the left side of the 
host processor. 
3.  To configure this device for the slave devices, right­click U1 and select Configure U1 
(WB_INTERCON)… 
4.  Referencing Figure 10, configure the following Slave Interfaces.

5­24 
Figure 10.  Wishbone interconnect component interfaces 

Note: The video capture interface will require Word addressing while all other 
interfaces will use Byte addressing. 
5.  Set the Unused Interrupts dropdown to Connect to GND and the Master Address 
Size dropdown to 24­Bit(Peripheral I/O). 

5.4  Managing memory access 
Like their traditional ‘hard’­processor counterparts; systems on FPGAs require memory 
resources.  Whether these resources exist on­chip or off­chip depends on the needs of the 
system and the device selected.  Generally, on­chip memory is faster but consumes device 
resources.  Off­chip memory on the other hand, though generally slower, has potentially 
greater storage capacity. 

For our application the bulk of our memory resources will exist off­chip as SRAM on the 
Spartan 3 Daughtercard.  The memory controllers however will exist on­chip, as will the 
arbiters that will manage memory access. 

5.5  Arbitration of multiple masters sharing a single slave 
In our system, we are again faced with a single bus to connect multiple soft devices, though in 
the case of memory the challenge is somewhat different as rather than managing a single 
master to multiple slaves, we are instead made to manage multiple masters sharing a single 
slave interface.  The single [slave] interface exists on the memory controller side and 
arbitration must occur to ensure that there is never more than one master device accessing 
memory at a time.  Likewise, there are issues of priority that arise. 

In our design, one block of memory will be shared by the Capture Controller and the Host 
Processor.  Another will be shared by the Display Driver and the Host Processor.  The

5­25 
processor will effectively access the video data from the Capture Memory and then write that 
data to the Display Memory, zoomed and rotated per the user’s input. 

BT656 Controller 

K6R4016V1D­TC10 

K6R4016V1D­TC10 
XRAM1 

SAMSUNG 

SAMSUNG 
SRAM Controller 

TSK3000 

K6R4016V1D­TC11 

K6R4016V1D­TC11 
XRAM2 

SAMSUNG 

SAMSUNG 
SRAM Controller 

VGA TFT Controller 

Figure 11. Block diagram showing the layout of the memory system 

This means that for each of the two blocks of memory, we will require an arbiter to control 
memory access.  This will ensure that both the host processor and the peripheral (whether 
the Capture Controller or the Display Driver) are not attempting to access the same memory 
at the same time. 

5.6  Wishbone Dual­ and Multi­ Master devices 
Altium Designer includes two types of arbiters, the Wishbone Dual Master (for managing two 
Masters’ access to a single Slave) and the more extensible Wishbone Multi Master 
component (for managing up to 8 Masters’ access to a single Slave device). 
Wishbone Multi Master  Wishbone Dual Master 

m1_STB_I  STB_O  m0_STB_I  STB_O  Figure 12. Wishbone 


No Delay 
m1_CYC_I 
m1_ACK_O 
CYC_O 
ACK_I 
m0_CYC_I 
m0_ACK_O 
CYC_O 
ACK_I 
dual­ and multi­ master 
m1_ADR_I[31..0] 
m1_DAT_O[31..0] 
ADR_O[31..0] 
DAT_I[31..0] 
m0_ADR_I[31..0] 
m0_DAT_O[31..0] 
ADR_O[31..0] 
DAT_I[31..0] 
components
m1_DAT_I[31..0]  DAT_O[31..0]  m0_DAT_I[31..0]  DAT_O[31..0] 
m1_SEL_I[3..0]  SEL_O[3..0]  m0_SEL_I[3..0]  SEL_O[3..0] 
m1_WE_I  WE_O  m0_WE_I  WE_O 
m1_CLK_I  CLK_O  m0_CLK_I  CLK_O 
m1_RST_I  RST_O  m0_RST_I  RST_O 

m2_STB_I 
m2_CYC_I 
m2_ACK_O 
m2_ADR_I[31..0] 
m2_DAT_O[31..0] 
m2_DAT_I[31..0] 
m2_SEL_I[3..0] 
m2_WE_I 
m2_CLK_I  m1_STB_I 
m2_RST_I  m1_CYC_I 
m1_ACK_O 
WB_MULTIMASTER  m1_ADR_I[31..0] 
m1_DAT_O[31..0] 
m1_DAT_I[31..0] 
m1_SEL_I[3..0] 
m1_WE_I 
m1_CLK_I 
m1_RST_I 

WB_DUALMASTER 

5­26 
As we will be making changes later that will require the addition of another Master accessing 
each of these two memories, we will utilize the Wishbone Multi Master components in our 
design.  The Wishbone Multi Master features:

· Support for up to 8 Wishbone Masters
· Ability to control address and data bus widths
· Ability to specify Master accessing mode: 
­  Round­Robin – giving masters access to the slave in sequence (top to 
bottom) 
­  Priority – allowing you to define an order of priority for access to the slave
· Ability to grant one Master instant access to the bus when in 'idle' state
· Supports passing of interrupts from a connected Wishbone Interconnect, through to 
all connected 32­bit processors (when used to share slave peripheral I/O devices). 

5.7  Configuring the wishbone multi­ master component 
The Wishbone Interconnect component can be configured by right­clicking the component in 
schematic and selecting Configure <RefDes> (WB_MULTIMASTER) or by launching the 
component properties dialog and hitting the Configure button at the lower left. 

Figure 13. Wishbone multi­ master configuration dialog

5­27 
In this dialog are options to Add, Remove, and Edit the banks of Wishbone Slave device 
interfaces, as well as options to Move Up and Move Down, physically reordering the location 
of the banks with respect to the schematic symbol.  The following table lists the various 
options available for configuring masters’ access to a slave device. 

Option  Description 
Type  Enables you to specify the way in which the 
Wishbone Masters contest for the slave 
resource.  The following options are available:
· Round Robin ­ masters access the slave in 
sequence, from first (top) to last (bottom).
· Priority – masters access the slave in the 
specified order of priority. 
Masters  Allows you to specify how many master 
interfaces the device will have (up to 8 masters 
are supported) 
Round Robin / Priority Order  Displays the Type and number of masters 
specified. 
If Type is set to Round Robin, only the Name 
and Spaces After Pins columns will be 
displayed.  The shared resource will be 
accessed by each master in turn, from the top of 
the list down. If Type is set to Priority, a third 
Priority column will be displayed allowing you to 
specify an explicit priority (1 being highest 
priority). 
Use the Name field to change the prefix for each 
master. Use the Spaces After Pins field to 
determine the amount of blank space that is 
inserted after the bank of pins for that master 
interface. 
Masters With No Delay  Allows you to specify one master to be granted 
instant access to the bus when the 
WB_MULTIMASTER is 'idle'. This reduces 
latency as the nominated master experiences no 
delay in acquiring access. Typically, when 
operating in Priority mode, the master specified 
here will be the one assigned highest priority. 
The interface assigned to be the master with no 
delay is distinguished on the schematic symbol 
by insertion of the text "No Delay".

5­28 
Option  Description 
Address Bus Width  Allows you to specify the number of address bits 
required to drive the connected slave device. 
The width chosen is applied to all interfaces of 
the WB_MULTIMASTER. 
When connecting to a single slave memory 
device you need to set the address bus to the 
same width as the ADR_I line for the Memory 
Controller. The Memory Controller will 
automatically size its ADR_I line according to the 
size of the physical memory it is connecting to. 
A Wishbone Interconnect must then be used 
between the Multi­Master and the processor's 
External Memory Interface, to handle the 
address line mapping. 
When connecting to a bank of physical memory 
devices through a Wishbone Interconnect, the 
address bus must be set to 32 Bits ­ Range = 
4GB, which matches the ADR_I line of the 
Interconnect's master interface. 
When connecting to a single slave peripheral 
device, you need to set the Multi­Master's 
address bus to the same width as the ADR_I line 
for the peripheral. A Wishbone Interconnect must 
then be used between the Multi­Master and the 
processor's Peripheral I/O Interface, to handle 
the address line mapping. 
When connecting to a bank of peripheral devices 
through a Wishbone Interconnect, the address 
bus must be set to 24 Bits ­ Range = 16MB, 
which matches the ADR_I line of the 
Interconnect's master interface. 

Data Bus Width  Allows you to specify the resolution of the data 
bus for the slave device being connected. 8­bit, 
16­bit and 32­bit data bus widths are supported. 
The width chosen is applied to all interfaces of 
the WB_MULTIMASTER. 

Interrupts  Enable the Show Interrupt Pins option in this 
region of the dialog to add the INT_O[31..0] and 
INT_I[31..0] pins to the master and slave 
interfaces respectively. The interrupt pins would 
be added when the Multi­Master device is used 
to connect multiple 32­bit processors to a bank 
of peripheral I/O devices, via a Wishbone 
Interconnect. 

This allows interrupts generated by those 
peripherals to be passed from the Interconnect 
through to the processors.

5­29 
5.8  Exercise 5 – Defining our Multi Master Components 
In this exercise we will place and configure the Wishbone Multi Master components required 
by our design.  These components will function as arbiters to manage access to the 
external memory used by our system. 
1.  From the libraries panel, select the FPGA Peripherals.IntLib  and place 2 
Wishbone Multi Master components WB_MULTIMASTER  along the right side of the host 
processor.  Designate these U3 and U12. 
2.  Right click U3 and select Configure U3 (WB_MULTIMASTER)  to launch the 
configuration dialog.  We will configure this device for both the host processor as well 
as the BT656 Video Capture Controller. 
3.  Configure U3 and U12 as seen in the figure below. 

Figure 14. U3 and U12 Wishbone MultiMaster configuration dialogs

5­30 
6  Interfacing to External Memory 
Altium Designer includes a Wishbone Compatible Configurable Memory Controller 
WB_MEM_CTRL that, depending on its configuration, provides a simple interface between a 32­ 
bit processor and either single data rate Synchronous DRAM, Asynchronous Static RAM, 32­ 
bit wide Block RAM (single or dual port), or parallel Flash memory. 

SRAM Controller 
STB_I  SRAM0_D[15..0] 
CYC_I  SRAM0_A[17..0] 
ACK_O  SRAM0_CE 
ADR_I[19..0]  SRAM0_WE 
DAT_O[31..0]  SRAM0_OE 
DAT_I[31..0]  SRAM0_UB 
SEL_I[3..0]  SRAM0_LB 
WE_I 
CLK_I  SRAM1_D[15..0] 
RST_I  SRAM1_A[17..0] 
SRAM1_CE 
SRAM1_WE 
SRAM1_OE 
SRAM1_UB 
SRAM1_LB 

WB_MEM_CTRL 

Figure 15. Wishbone Configurable Memory Controller 

The Memory Controller (Figure 15) features:

· Simplified connection to processor’s External Memory interface via a Wishbone 
Interconnect
· Configurable as either SRAM, SDRAM, or BRAM Controller 
­  SDRAM Controller – interfaces to 8­, 16, or 32­bit wide SDR SDRAM 
­  SRAM Controller – interfaces to 8­, 16, or 32­bit wide asynchronous SRAM 
­  BRAM Controller – interfaces to 32­bit wide single or dual port Block RAM 
­  Flash Controller – interfaces to 8­, 16, or 32­bit wide parallel Flash memory
· Automatic sizing of ADR_I input bus, based on specified physical memory size
· Wishbone­compliant interface 

6.1  Configuring the SRAM Controller 
The SRAM Controller component can be configured by right­clicking the component in 
schematic and selecting Configure <RefDes> (WB_MEM_CTRL) or by launching the 
component properties dialog and hitting the Configure button at the lower left.

6­31 
Figure 16. Wishbone Configurable Memory Controller configuration dialog 

In this dialog are options to configure the memory controller for use with a variety of different 
memory sizes and types.  The following table provides a description of the various options 
available when configuring the memory controller. 

Option  Description 
Memory Type  Specifies the type of memory that you wish to 
interface to. Choose from either:
· Synchronous DRAM
· Asynchronous SRAM
· Block RAM
· Parallel FLASH 
The configuration options presented in the 
dialog will change with your selection. 

Size Of <Memory Type>  Specifies the size of the physical RAM that you 
are interfacing to. The width of the interface 
address bus(es) and also the ADR_I input line 
will update accordingly upon leaving the dialog. 
This dialog will update dynamically as the 
Memory Type changes.

6­32 
Option  Description 
Size Of <Memory Type>  Specifies the size of the physical RAM that you are 
interfacing to. The width of the interface address 
bus(es) and also the ADR_I input line will update 
accordingly upon leaving the dialog. 
This dialog will update dynamically as the Memory 
Type changes. 

Memory Layout  Used to select the layout for the physical memory.  The 
schematic symbol for the placed Memory Controller 
will automatically be updated to reflect your selection, 
upon leaving the dialog. 
In addition to determining the interface pinout for 
connection to the physical memory device(s), the 
memory layout also determines the number of 
accesses required to read or write a single 32­bit word. 
In the case of BRAM, this region of the dialog is non­ 
editable and reflects the layout of physical BRAM that 
can be connected to the Controller 
Clock cycles for Reading  Only editable when using Parallel Flash, this option 
allows you to specify the number of clock cycles (of 
CLK_I) required to perform a read operation. 

Clock cycles for Writing  Only editable when using Parallel Flash, this option 
allows you to specify the number of clock cycles (of 
CLK_I) required to perform a write operation. 

Memory Settings  Only visible when using SDRAM, this option allows you 
to specify the SDRAM’s clock frequency in MHZ.  The 
frequency of the signal arriving at the controller’s 
SDRAM_CLK input must match this clock frequency. 
The Keep Current Row Option allows you to keep the 
current row open – essentially disabling the SDRAM 
device’s auto­precharge feature which otherwise 
causes a precharge of the addressed bank/row upon 
completion of the current Read or Write. 

Timer Settings  Only visible when using SDRAM, these options allow 
you to specify the Write Recovery Time (tWR), Auto 
Refresh period (tRFC), Active to Read or Write delay 
(tRCD), Precharge command period (tRP), and CAS 
latency (tCAS).  Each of these values is specified in 
terms of the number of cycles of the SDRAM_CLK 
signal. 
The dropdown allows you to define the synchronization 
scheme to be used when interfacing to SDRAM. 
Ensure that the frequency of the signal wired to the 
Controller's SDRAM_CLK input is in accordance with 
the synchronization setting you have chosen. 

6.2  The Shared Memory Controller 
Altium Designer also includes a Wishbone Compatible Shared Memory Controller core 
WB_SHARED_MEM_CTRL that, depending on its configuration, provides a simple interface 
between a 32­bit processor and memories on a shared bus.

6­33 
Shared Memory Controller 
SRAM_STB_I  MEM_D[31..0] 
SRAM_CYC_I  MEM_A[23..0] 
SRAM_ACK_O  MEM_W 
SRAM_ADR_I[19..0]  MEM_OE 
SRAM_DAT_O[31..0]  MEM_BE[3..0] 
SRAM_DAT_I[31..0]  MEM_SDRAM_CKE 
SRAM_SEL_I[3..0]  MEM_SDRAM_RAS 
SRAM_WE_I  MEM_SDRAM_CAS 
SRAM_CLK_I  MEM_SDRAM_E 
SRAM_RST_I  MEM_FLASH_BUSY 
MEM_FLASH_RESET 
MEM_FLASH_E 
MEM_SRAM_E 

WB_SHARED_MEM_CTRL 

The Controller provides access to, and use of, the following three different types of memory, 
each of which is multiplexed for access over shared data and address busses:

· Asynchronous Static RAM
· Single data rate Synchronous DRAM
· Parallel Flash memory 

The Controller handles all multiplexing for you, negating the need for custom demultiplexing 
logic. 

Note: The WB_SHARED_MEM_CTRL is primarily designed to be used with the common­bus 
memories located on Altium's 3­connector daughter boards, such as the Xilinx Spartan­3 
Daughter Board DB30. Provided the same pinout is used, the Controller could be used to 
interface to other memories of the types supported, and which are accessed using a shared 
bus architecture. 

6.3  Configuring the Shared Memory Controller 
The SRAM Controller component can be configured by right­clicking the component in 
schematic and selecting Configure <RefDes> (WB_SHARED_MEM_CTRL) or by launching 
the component properties dialog and hitting the Configure button at the lower left.

6­34 
In this dialog are options to configure the memory controller for use with a variety of different 
memory sizes and types.  For a complete list of configuration options, see the reference 
CR0176 WB_SHARED_MEM_CTRL Configurable Shared Memory Controller.pdf 
found under the Help menu our available from the Altium website.  For our design we will be 
configuring the device as Asynchronous RAM and the following table provides a description of 
the various options available when configuring the memory controller. 

Option  Description 
Memory Size  Use this region of the page to specify the size of the 
physical memory that you are interfacing to. For 
example, the common­bus SRAM on a 3­connector 
daughter board is provided by two 4Mbit, high­speed 
CMOS SRAM devices. Each device is organized as 
256K x 16 bits – combined together to give 256K x 32­ 
bit storage (1MByte). 
The width of the SRAM_ADR_I input line will 
automatically change according to memory size 
specified. 

Memory Layout  Use the drop­down available in this region of the page 
to select the layout for the physical memory. 
In addition to determining the interface pinout for 
connection to the physical memory device(s), the 
memory layout also determines the number of 
accesses required to Read or Write a single 32­bit 
word. 

Timing Settings  This region of the page enables you to specify 
additional clock cycles (cycles of SRAM_CLK_I) to be 
added for each stage of a Read and Write operation. 
Each stage must be at least one clock cycle. 
The minimum number of clock cycles for each 
operation are:
· Read – two clock cycles. If the system clock 
(SRAM_CLK_I) is 50MHz, this equates to 
40ns.

6­35 
· Write – three clock cycles. With a system 
clock (SRAM_CLK_I) of 50MHz, this equates 
to 60ns. 
The following default timing settings are used:
· Clock cycles for address setup – 1 cycle
· Clock cycles for write pulse – 1 cycle
· Clock cycles for post­write address hold – 1 
cycle. 

6.4  Exercise 6 – Placing and configuring memory controllers 
In this exercise we will place and configure the Configurable Wishbone Memory Controller 
WB_MEM_CTRL  and the  Wishbone Shared Memory Controller WB_SHARED_MEM_CTRL. 
These controllers will serve as the FPGA­side interface to 2MB of Asynchronous SRAM 
located on the Spartan 3 FPGA Daughterboard. 

1.  From the libraries panel, select the FPGA Peripherals.IntLib  and place the 


Configurable Memory Controller components WB_MEM_CTRL  along the right side of the 
Wishbone Multi Master component.  Designate this component U4. 
2.  Right click U4 and select Configure U4 (WB_MEM_CTRL)… to launch the 
configuration dialog. Configure U4 as it appears in Figure 17. 

Figure 17. Configuring the wishbone memory controller U4 

3.  Return to the FPGA Peripherals.IntLib  and place the Shared Memory Controller 


components WB_SHARED_MEM_CTRL  along the right side of the Wishbone Multi Master 
component.  Designate this component U13. 
4.  Right click U13 and select Configure U13 (WB_SHARED_MEM_CTRL)… to launch 
the configuration dialog. Configure U13 as it appears in Figure 18.

6­36
Figure 18. Configuring the wishbone shared memory controller U13 

6.5  Exercise 7 – Multiple memories as slaves 
Our host processor will require a second Wishbone Interconnect component as each of the 
two arbiters appears as slaves to the processor’s memory interface.  In this exercise we will 
add a second Configurable Wishbone Interconnect component and configure it for the two 
memories in our design. 
1.  From the libraries panel, select the FPGA Peripherals.IntLib  and place a 
Configurable Wishbone Interconnect component WB_INTERCON  to the right side of the 
host processor.  Designate this component U8. 
2.  Right click the component and select Configure U8 (WB_INTERCON)… to launch the 
component’s configuration dialog. 
3.  In the configuration dialog, configure this component as it appears in Figure 19. 

Figure 19. Configuring the wishbone interconnect to support multiple memory slaves

6­37 
6.6  Exercise 8 – Placing the Port Plug In Components 
Each of the peripherals that we have placed thus far will connect to the corresponding 
hardware on the NanoBoard using a Port Plug In component located in one of the various 
Port Plug In libraries detailed in our discussions on Day 1.  In this exercise we will place the 
required Port Plug In components and arrange them such that we might simplify the 
connectivity. 

1.  Locate the FPGA PB01 Port­Plugin.IntLib in the Libraries panel and place the following 
components arranged along the left side of the FPGA peripherals as seen in Figure 20.
· VIDEO_INPUT
· VIDEO_INPUT_CTRL 
2.  Locate the FPGA NB2DSK01 Port­Plugin.IntLib in the Libraries panel and place the 
following components arranged along the left side of the FPGA peripherals as seen in 
Figure 20.
· CLOCK_BOARD
· TEST_BUTTON
· LED
· TFT_LCD
· NEXUS_JTAG_CONNECTOR 

3.  Locate the FPGA DB Common Port­Plugin.IntLib in the Libraries panel and place the 
following components arranged along the left side of the FPGA peripherals as seen in 
Figure 20.
· SRAM_DAUGHTER0
· SRAM_DAUGHTER1
· SHARED_SRAM_DAUGHTER 

4.  Locate the FPGA Generic.IntLib in the Libraries panel and place the following 
components.
· NEXUS_JTAG_PORT
· INV 
5.  Designate the Inverter U16. 

No reference designators will be required for any parts other than the inverter as the 
remaining parts are not components of the FPGA but rather ports referencing components 
external to the FPGA project.  The fact that these have been collected into a library and can 
be placed as components is intended only to simplify the process of developing FPGAs using 
the Desktop NanoBoard. 

The schematic in Figure 20 displays how to arrange the components to ensure ease in wiring. 
Notice the way in which each of the Wishbone Interfaces can be aligned to simplify this 
process.

6­38 
Figure 20. Schematic including the required port plug­in components

6­39 
6.7  Exercise 10 – Wiring Up Your FPGA Design 
In this exercise we will wrap up the capture portion of our design by wiring up our schematic. 
As in Day 1, these wires represent physical connections inside the FPGA whether between 
blocks of FPGA IP or to pins of the FPGA device (as is the case of the NanoBoard Port Plug 
In components). 

With the assistance of your instructor, wire the design as it appears in Figure 21.  Snippets 
have been added to the Snippets panel to assist you in making this process faster.  Be sure 
to include bus joiners and bus power ports as required.

6­40 
U5  U1  U2  U3  U4 

BT656 Controller  Wishbone Interconnect  TSK3000A 32­Bit RISC Processor  Wishbone Multi Master  SRAM Controller 


MCU_STB  MCU1_STB 
VIDIN_DATA[7..0]  VID_DATA[7..0]  WBS_STB_I  s0_STB_O  m0_STB_I  IO_STB_O  ME_STB_O  MCU_STB_I  STB_O  STB_I  SRAM0_D[15..0]  SRAM0_D[15..0] 
MCU_CYC  MCU1_CYC 
VIDIN_PCLK  PCLK  WBS_CYC_I  s0_CYC_O  m0_CYC_I  IO_CYC_O  ME_CYC_O  MCU_CYC_I  CYC_O  CYC_I  SRAM0_A[17..0]  SRAM0_A[17..0] 
MCU_ACK  MCU1_ACK  No Delay 
VIDIN_INTERQ_GPLC  VBLK  WBS_ACK_O  s0_ACK_I  m0_ACK_O  IO_ACK_I  ME_ACK_I  MCU_ACK_O  ACK_I  ACK_O  SRAM0_CE  SRAM0_E 
MCU_ADR[31..0]  MCU1_ADR[19..0] 
WBS_ADR_I[2..0]  s0_ADR_O[2..0]  m0_ADR_I[23..0]  IO_ADR_O[23..0]  ME_ADR_O[31..0]  MCU_ADR_I[19..0]  ADR_O[19..0]  ADR_I[19..0]  SRAM0_WE  SRAM0_W 
TVP5150AM1  MCU_DIN[31..0]  MCU1_DIN[31..0] 
VIDIN_AVID  WBS_DAT_O[31..0]  s0_DAT_I[31..0]  m0_DAT_O[31..0]  IO_DAT_I[31..0]  ME_DAT_I[31..0]  MCU_DAT_O[31..0]  DAT_I[31..0]  DAT_O[31..0]  SRAM0_OE  SRAM0_OE 
MCU_DOUT[31..0]  MCU1_DOUT[31..0] 
VIDIN_HSYNC  WBS_DAT_I[31..0]  s0_DAT_O[31..0]  m0_DAT_I[31..0]  IO_DAT_O[31..0]  ME_DAT_O[31..0]  MCU_DAT_I[31..0]  DAT_O[31..0]  DAT_I[31..0]  SRAM0_UB  SRAM0_UB 
MCU_SEL[3..0]  MCU1_SEL[3..0] 

SAMSUNG 
K6R4016V1D­TC10 
VIDIN_VSYNC  WBS_SEL_I[3..0]  s0_SEL_O[3..0]  m0_SEL_I[3..0]  IO_SEL_O[3..0]  ME_SEL_O[3..0]  MCU_SEL_I[3..0]  SEL_O[3..0]  SEL_I[3..0]  SRAM0_LB  SRAM0_LB 
MCU_WE  MCU1_WE 
VIDIN_FID_CLCO  WBS_WE_I  s0_WE_O  m0_WE_I  IO_WE_O  ME_WE_O  MCU_WE_I  WE_O  WE_I 
MCU_CLK  MCU1_CLK 
CLK_I  s0_CLK_O  m0_CLK_I  IO_CLK_O  ME_CLK_O  MCU_CLK_I  CLK_O  CLK_I  SRAM1_D[15..0]  SRAM1_D[15..0] 
MCU_RST  MCU1_RST 
RST_I  s0_RST_O  m0_RST_I  IO_RST_O  ME_RST_O  MCU_RST_I  RST_O  RST_I  SRAM1_A[17..0]  SRAM1_A[17..0] 
INT_O[1..0]  m0_INT_O[31..0]  INT_I[31..0]  SRAM1_CE  SRAM1_E 
SRAM1_WE  SRAM1_W 
Current Configuration  SRAM1_OE  SRAM1_OE 
VID_STB  VID_STB 
WBM_STB_O  VIDEO_STB_I  SRAM1_UB  SRAM1_UB 
VID_CYC  VID_CYC  High Priority 
SAMSUNG 
K6R4016V1D­TC10 

WBM_CYC_O  MDU              : Installed  VIDEO_CYC_I  SRAM1_LB  SRAM1_LB 


VID_ACK  VID_ACK 
WBM_ACK_I  Debug Hardware   : Installed  VIDEO_ACK_O 
VID_ADR[31..0]  VID_ADR[19..0] 
WBM_ADR_O[31..0]  Internal Memory  : 32 KB  VIDEO_ADR_I[19..0] 
WB_MEM_CTRL 
VIDEO_DAT_O[31..0] 
VID_DOUT[31..0]  VID_DOUT[31..0] 
WBM_DAT_O[31..0]  VIDEO_DAT_I[31..0] 
VID_SEL[3..0]  VID_SEL[3..0] 
WBM_SEL_O[3..0]  VIDEO_SEL_I[3..0] 
VID_WE  TSK3000A  CLK  CLK_I  VID_WE 
WBM_WE_O  VIDEO_WE_I 
RST  RST_I  CLK 
VIDEO_CLK_I 
BT656  RST 
VIDEO_RST_I 
U7 

U8  WB_MULTIMASTER 
I2C Master Whishbone 

SDATA_EN  STB_I  s1_STB_O  Wishbone Interconnect 


U9 
CYC_I  s1_CYC_O 
MCU_STB  MCU1_STB 
SDATAO  ACK_O  s1_ACK_I  m0_STB_I  s0_STB_O 
MCU_CYC  MCU1_CYC 
ADR_I[2..0]  s1_ADR_O[2..0]  m0_CYC_I  s0_CYC_O 
MCU_ACK  MCU1_ACK 
SDATAI  DAT_O[7..0]  s1_DAT_I[7..0]  m0_ACK_O  s0_ACK_I 
MCU_ADR[31..0]  MCU1_ADR[19..0] 
SDA  DAT_I[7..0]  s1_DAT_O[7..0]  m0_ADR_I[31..0]  s0_ADR_O[19..0] 
TVP5150AM1  MCU_DIN[31..0]  MCU1_DIN[31..0] 
SCL  SCLK_EN  s1_SEL_O[3..0]  m0_DAT_O[31..0]  s0_DAT_I[31..0] 
U10  MCU_DOUT[31..0]  MCU1_DOUT[31..0] 
WE_I  s1_WE_O  m0_DAT_I[31..0]  s0_DAT_O[31..0] 
MCU_SEL[3..0]  MCU1_SEL[3..0] 
SCLKO  CLK_I  s1_CLK_O  m0_SEL_I[3..0]  s0_SEL_O[3..0] 
MCU_WE  MCU1_WE 
RST_I  s1_RST_O  m0_WE_I  s0_WE_O 
MCU_CLK  MCU1_CLK 
SCLKI  INT_O  m0_CLK_I  s0_CLK_O 
MCU_RST  MCU1_RST 
m0_RST_I  s0_RST_O 
I2CM_W 
U14 
MCU2_STB 
s1_STB_O 
MCU2_CYC 
Port Wishbone  s1_CYC_O 
MCU2_ACK 
s1_ACK_I 
MCU2_ADR[19..0] 
LEDS[7..0]  PAO[7..0]  STB_I  s2_STB_O  s1_ADR_O[19..0] 
MCU2_DIN[31..0] 
CYC_I  s2_CYC_O  s1_DAT_I[31..0] 
MCU2_DOUT[31..0] 
ACK_O  s2_ACK_I  s1_DAT_O[31..0] 
MCU2_SEL[3..0] 
s1_SEL_O[3..0] 
MCU2_WE 
s2_DAT_I[7..0]  s1_WE_O 
MCU2_CLK 

GND 
DAT_I[7..0]  s2_DAT_O[7..0]  s1_CLK_O 
MCU2_RST 
s2_SEL_O[3..0]  s1_RST_O 
WE_I  s2_WE_O 

Figure 21. Completed schematic with the required wiring
CLK_I  s2_CLK_O  WB_INTERCON 
RST_I  s2_RST_O 
U12  U13 
WB_PRTIO 
Wishbone Multi Master  Shared Memory Controller 
U17 
MCU2_STB 
MCU_STB_I  STB_O  SRAM_STB_I  MEM_D[31..0]  BUS_D[31..0] 
MCU2_CYC 
Wishbone Display Driver  MCU_CYC_I  CYC_O  SRAM_CYC_I  MEM_A[23..0]  BUS_A[24..1] 
MCU2_ACK  No Delay 
DAU_TFT_IRQ  MCU_ACK_O  ACK_I  SRAM_ACK_O  MEM_W  BUS_NWE 
MCU2_ADR[19..0] 
DAU_TFT_RED[4..0]  TFT_RED[4..0]  io_STB_I  s3_STB_O  MCU_ADR_I[19..0]  ADR_O[19..0]  SRAM_ADR_I[19..0]  MEM_OE  BUS_NOE 
MCU2_DIN[31..0] 
DAU_TFT_GREEN[5..0]  TFT_GREEN[5..0]  io_CYC_I  s3_CYC_O  MCU_DAT_O[31..0]  DAT_I[31..0]  SRAM_DAT_O[31..0]  MEM_BE[3..0]  BUS_NBE[3..0] 
MCU1_DOUT[31..0] 
DAU_TFT_BLUE[4..0]  TFT_BLUE[4..0]  io_ACK_O  s3_ACK_I  MCU_DAT_I[31..0]  DAT_O[31..0]  SRAM_DAT_I[31..0]  MEM_SDRAM_CKE  BUS_SDRAM_CKE  VCC 
MCU2_SEL[3..0] 
DAU_TFT_CL[3..1]  TFT_CL[3..1]  io_ADR_I[11..0]  s3_ADR_O[11..0]  MCU_SEL_I[3..0]  SEL_O[3..0]  SRAM_SEL_I[3..0]  MEM_SDRAM_RAS  BUS_SDRAM_NRAS  VCC 
MCU2_WE 
DAU_TFT_DISP_ON  TFT_DISP_ON  io_DAT_O[31..0]  s3_DAT_I[31..0]  MCU_WE_I  WE_O  SRAM_WE_I  MEM_SDRAM_CAS  BUS_SDRAM_NCAS  VCC 
MCU2_CLK 
DAU_TFT_M  TFT_M  io_DAT_I[31..0]  s3_DAT_O[31..0]  MCU_CLK_I  CLK_O  SRAM_CLK_I  MEM_SDRAM_E  BUS_SDRAM_NCS  VCC 
MCU2_RST 
DAU_TFT_POL  TFT_POL  io_SEL_I[3..0]  s3_SEL_O[3..0]  MCU_RST_I  RST_O  SRAM_RST_I  MEM_FLASH_BUSY  BUS_FLASH_NBUSY  X 
SAMSUNG 
K6R4016V1D­TC10 
SAMSUNG 
K6R4016V1D­TC10 

DAU_TFT_STH  TFT_STH  io_WE_I  s3_WE_O  MEM_FLASH_RESET  BUS_FLASH_NRESET VCC 


DAU_TFT_STV  TFT_STV  io_CLK_I  s3_CLK_O  MEM_FLASH_E  BUS_FLASH_NCS  VCC 
DAU_TFT_MUX  io_RST_I  s3_RST_O  MEM_SRAM_E  BUS_RAM_NCS 
TFT_STB 

VCC 
DAU_TFT_BLIGHT  io_INT_O[2..0]  TFT_STB_I  BUS_SDRAM_CLK  GND 
TFT_CYC  High Priority 
WB_INTERCON  TFT_CYC_I 
TFT_STB  TFT_ACK 
me_STB_O  TFT_ACK_O 
TFT_CYC  TFT_ADR[19..0] 
me_CYC_O  TFT_ADR_I[19..0]  WB_SHARED_MEM_CTRL 
TFT_ACK  TFT_DIN[31..0] 
me_ACK_I  TFT_DAT_O[31..0] 
GND 

TFT_ADR[19..0] 
me_ADR_O[19..0]  TFT_DAT_I[31..0] 
TFT_DIN[31..0]  TFT_SEL[3..0] 
me_DAT_I[31..0]  GND  TFT_WE 
TFT_SEL_I[3..0] 
TFT_WE_I 
TFT_SEL[3..0]  CLK 
me_SEL_O[3..0]  TFT_CLK_I 
TFT_WE  RST 
me_WE_O  TFT_RST_I 

WB_VGA 
WB_MULTIMASTER 

JTAG_NEXUS_TDI  TDI  JTAG 

JTAG 
JTAG_NEXUS_TDO  TDO 
JTAG 
JTAG_NEXUS_TCK  TCK  JTAG 

JTAG_NEXUS_TMS  TMS  JTAG 





JTAG 
TRST 

VCC 
CLK 
CLK_BRD 

U16 
RST 
TEST_BUTTON 

INV 

6­41 
7  Configuring Processor Memory 
At this stage we have largely completed the FPGA portion of our design however one key 
step remains and that is the configuration of our processor memory from within the processor. 

In addition to the memory that is managed by each of the interconnect components within our 
design; you can also centrally manage memory from the processor’s memory and peripheral 
configuration dialog boxes.   These are accessed by right­clicking the processor and selecting 
Configure Processor Memory… and Configure Processor Peripheral…  respectively. 
Alternatively, both dialogs are accessible from within the component properties dialog for 
these components. 

Figure 22. Processor memory configuration dialog 

Below is a table that describes the various options within this dialog.

7­42 
Option  Description 

hardware.asm (Assembly File)  Used to pass the memory and peripheral 
definition information to the Embedded Software 
project in the form of a Header File.  A header 
file essentially provides keyword substitution. 
The Embedded Software designer can simply 
enter a definition into the code, which, through 
the header file, will be substituted with the 
required information at compile time.  This option 
produces a Header file in Assembly language. 

hardware.h (C Header File)  Used to pass the memory and peripheral 
definition information to the Embedded Software 
project in the form of a Header File.  This option 
produced a Header file as a C language file. 

Set to Default  Used to Reset the memory configuration to its 
default settings.  This option would only be used 
when the current memory configuration is out of 
date and needs to be re­done, or when the 
design does not contain a special or explicit 
configuration.  Use caution as this option does 
not provide a Warning dialog and can only be 
undone by hitting Cancel prior to closing the 
dialog or closing and reopening the schematic. 
Import From Schematic  Used when physical memory devices are 
connected to the processor through a Wishbone 
Interconnect.  This is the simplest way to make 
these devices 'known' to the processor as it 
automatically maps the devices into the 
processor's address space per the settings 
defined in the Wishbone Interconnect 
component’s configuration  dialog (as seen with 
the XRAM slave interfaces which had come up 
predefined in Exercise 10). 

Configure Application Memory  Used to define a memory configuration specific 
to a particular application. 

Configure Peripherals  Launches the Configure Peripherals dialog used 
to specify the peripherals as they are ‘seen’ by 
the processor through its Processor I/O space.  If 
using Wishbone compliant peripherals accessed 
through the Wishbone interconnect, this dialog 
may be populated automatically using the Import 
From Schematic option. 

7.1  Dividing the processor memory 
Though we have already defined the size of the Internal Processor Memory when we’d 
previously configured the device (this was 32K Bytes or 8K x 32­bit Words); Altium Designer 
affords us the ability to further carve out specific memories to appear in a particular way to the 
host processor.  So for example, though we have 32 Kbytes of memory, we will actually 
change the way the processor ‘sees’ this memory, carving it into 2, 16 Kbyte chunks.

7­43 
For our application, we will also need to partition the processor’s internal memory, specifying 
half of the internal memory (16 Kbytes) as ROM and the other half as RAM.  To do this, we 
need first to right­click in the Device Memory section of the Configure Processor Memory 
dialog and remove the large, 32 Kbytes section labeled U2.  We can then right­click and add 
the two smaller sections, configured for our application.  This will launch the Processor 
Memory Definition dialog that appears in Figure 23. 

Figure 23. Further configuring the processor memory 

From the Configure Processor Memory dialog we will further refine our processor memory by 
dividing the memory into two 16 Kbyte sections.  The table below describes the various 
options available from within this dialog. 
Option  Description 

Name  Used to specify a unique identifier for the device. 
The identifier used for each memory device will 
be used when generating header files for 
inclusion in the Embedded Software project. 
The identifiers will also be used to uniquely 
identify the corresponding output HEX files.  This 
field cannot contain spaces. 

Type  Used to specify the type and relative speed of 
the memory device.  The memory type can be 
either ROM or RAM (volatile or non­volatile). 
Speed ranges from 0 (fastest) to 5 (slowest). 
The Linker uses the speed settings for all 
defined memories to best optimize the overall 
performance and efficiency of the code.

7­44 
Option  Description 

Address Base  Used to specify the base address of the memory 
device.  Internal memory will always begin at 
base address 0000_0000h.  The processor’s 
internal memory range is 16MB and the actual 
size of the physical RAM mapped into this range 
will be driven by how much physical BRAM is 
available in the target FPGA. 
Base addresses can be specified as decimal or 
Hex notation (e.g. 10000, 0x10000, 1k, 64k, 1M). 

Size  Used to specify the size of the memory.  This 
value can be specified as decimal or Hex 
notation (e.g. 10000, 0x10000, 1k, 64k, 1M). 

7.2  Exercise 11 – Configuring the processor memory 
In this exercise we will configure the internal memory of the TSK3000 to suit our design. 

1.  Right­click U2 and select Configure Processor Memory…  to launch the Configure 


Processor Memory dialog 
2.  Enable the option to generate a hardware.h (C Header File). 
3.  Right click U2  in the list of memories and select Delete Memory.  Once deleted we will 
need to add our internal memories, this time partitioned as both ROM and RAM for our 
application. 
4.  To add the ROM and RAM blocks required, right click the list of memories and select 
Add Memory…  This will launch the Processor Memory Definition dialog. 
5.  Specify a new internal memory with the name irom, as a ROM type, with a Speed  of 0 
– Fastest, beginning at base address 0x0  and 16 Kbytes in size. 
6.  Create a second new internal memory with the name iram, as a RAM – Volatile 
type, with a Speed  of 0 – Fastest, beginning at base address 16k, and 16 
Kbytes in size. 

Once configured properly, the Configure Processor Memory dialog should appear as it does 
in Figure 24. 

Figure 24. Dividing up the processor memory.

7­45 
7.3  Configuring processor peripherals 
Though we’ve already specified the details of each peripheral including their bus widths, base 
address locations, etc. when we had configured the Wishbone Interconnect component U1, 
we still need to specify this information at the processor end. 
To configure processor peripherals, simply right­click the host processor in the schematic and 
select Configure Processor Peripheral…  This will launch the Configure Peripherals 
dialog seen in Figure 25. 

Figure 25. Configuring the processor peripherals at the processor end 

Peripherals can be imported into the processor’s IO space by selecting the option Import 
From Schematic.  This will prompt you with the option to delete existing peripherals before 
importing, after which, it will launch the Choose Wishbone Items dialog seen in Figure 26. 
Select Import under the Import to Bus option for any items you wish to import.

7­46 
Figure 26. Choose the wishbone peripherals to import 

7.4  Exercise 12 – Specifying processor peripherals 
In this exercise we will configure the peripheral memory of the TSK3000 to suit our 
design. 
1.  Right­click U2 and select Configure Processor Peripheral…  to launch the 
Configure Peripherals dialog. 
2.  Enable the option to generate a hardware.h (C Header File). 
3.  Select the option Import From Schematic to import the peripherals from the design. 
As we’ve not existing peripherals in our design it is safe to delete these before 
importing. 
4.  Select the option Import just beside U2 in the Choose Wishbone Items dialog.  This will 
cause the status of all items to change to Import.  Clicking OK will close the dialog and 
the memory listed in the Configure Peripherals dialog should now appear as it does in 
Figure 27. 

Figure 27. Processor peripherals properly configured for our application.

7­47 
8  Finalizing the Design, Compiling and 
Resolving Errors 
At this stage we have successfully completed the FPGA portion of our design.  It is now time 
to compile the FPGA project and correct any errors you might have in your design.  Once 
completed, save the FPGA schematic and FPGA project before continuing.

8­48 
9  Creating Embedded Systems on FPGAs 
Altium Designer supports a hierarchical approach to design, even at the project level with 
support for the linking of multiple projects to one another.  This includes the ability to link one 
or more FPGA projects to a PCB project, as well as the ability to link an embedded project to 
any FPGA project that uses a softcore processor. 

In this section of the course we will explore the creation of embedded projects, the debugging 
of software code using a software simulator, and some of the many options the TASKING 
toolset, including the best­in­class Viper compiler technology afford us when designing our 
applications. 

Likewise we will discuss linking embedded projects to an FPGA project and the process of 
building and running applications running on an FPGA. 

9.1  Exercise 13 – Editor Basics 
In this exercise we will create a simple embedded project that we will use to explore some of 
editor options available in Altium Designer.  We will also use this project later as we learn the 
basics of Compiling and Debugging our code. 

1.  From the File menu, select New»Project»Embedded Project. 
2.  Select the newly created embedded project Embedded_Project1.PrjEmb in the 
Projects panel and add a new C source document using File»New»C Source 
Document, or right­clicking the project document in the Projects  panel and selecting 
Add New to Project»C File. 

This will launch a blank text editor that we will use to enter our application code.  The 
buttons along the bottom of the system tray and the menus along the top will change to 
include options appropriate for developing our application. 

3.  In the Code editor, enter the following: 

#define Base_WB_PRTIO_1            0xFF400000 
#define Size_WB_PRTIO_1            0x00000001 

#include "hardware.h" 

#define LEDS   (*(unsigned char*)Base_WB_PRTIO_1) 

void main(void) 

LEDS = 0x55; 

Notice how the code is automatically formatted and the syntax is properly highlighted 
for the C language.  Altium Designer’s code editor features a broad range of powerful 
syntax highlighting capabilities with virtually limitless user configurability available under 
Tools»Formatting Options.

9­49 
Code Formatting ­ General 

Code formatting ­ Spacing 

Additional Code Formatting & Highlighting options are available under Tools»Editor 
Preferences…

9­50 
Preferences ­ General 

Preferences ­ Display

9­51 
Preferences ­ Colors 

4.  If time permits, experiment with some of the editor settings to see their effect on the 
source code.  Use Tools » Format Source Code after making each change to update 
your source code in the code editor.

9­52 
9.2  The TASKING tool chain 
Many long­time users of Altium Designer are familiar with its advanced schematic and PCB 
capabilities and can understand how schematic­based FPGA development is a natural 
extension of Altium’s core technologies.  Delving into the world of embedded systems 
programming however represents a significant departure from this hardware focus. 

Altium, through their corporate acquisition of TASKING, are a major player in the embedded 
systems marketplace.  TASKING products are world­leading tools for embedded software 
development, bringing together the advanced software design technology needed to compete 
in the embedded systems marketplace. The award­winning TASKING integrated development 
environment, compiler, debugger, embedded Internet and RTOS offerings support a wide 
range of DSPs and 8­, 16­ and 32­bit microprocessors and microcontrollers for all areas of 
embedded development. With over 100,000 licensed users of TASKING products, including 
the world's leading telecom, datacom, wireless and peripheral manufacturers, the TASKING 
product range has a long history of technology leadership and innovation. 

9.3  The Build flow 

Figure 28. A look at the TASKING build flow. 

Building an application is the process of compiling all of the top­level source documents into a 
binary file that can be executed by a target processor.  This is a multi­step process involving a 
number of tools.  In many situations, the user will be shielded from the detail of the underlying 
compilation processes however in some circumstances it will be necessary to diagnose the source 
of build or compilation errors and for this it is important to understand the compilation flow.

9­53 
The C compiler, assembler and debugger are target dependent, whereas the linker and the 
librarian are target independent. The bold names in Figure 28 are the executable names of 
the tools. Substitute target with one of the supported target names, for example, c3000 is the 
TSK3000 C compiler and c51 is the 8051 C compiler. 

9.4  Targeting the Project 
Prior to compiling an embedded project, it is necessary to notify the compiler which processor 
we intend to use and any special compilation features we may wish to include.  This is done 
via the Project Options dialogue box that can be accessed by right­clicking the Embedded 
Project in the Projects panel and selecting Project Options panel or by selecting Project » 
Project Options from the main menu. 

9.5  Project options 
The Options for Embedded Project dialog contains the configuration options specific to the 
process of compiling, linking, and locating your design.  This dialog also contains other 
options such as the option to specify what processor is being targeted, whether or not to 
include the Device Software Framework (more on that later in this section), as well as other 
options. 

9.5.1  Device 
Select from a range of 8 and 32­bit processors including FPGA­based and non FPGA­based 
devices.  Currently Altium Designer supports the following list of hard and soft processors. 

Processor  Description 
TSK51  The TSK51x is the core of a fast, single­chip, 8­ 
bit microcontroller, which executes all ASM51 
instructions and is instruction set compatible with 
the 80C31. The TSK51x serves software and 
hardware interrupts, provides an interface for 
serial communications and incorporates a timer 
system. 

TSK52  The TSK52x is an 8­bit embedded controller that 
executes all ASM51 instructions and is 
instruction set compatible with the 80C31. 

TSK80  The TSK80x is a fully functional 8­bit embedded 
processor which is instruction set compatible 
with the Zilog Z80CPU. 
The TSK80x supports hardware interrupts, halt 
and wait states for low speed memory and I/O 
devices. 

TSK165x  The TSK165x is a fully functional, 8­bit controller 
that employs RISC architecture with a 
streamlined set of single word instructions. 
The TSK165x is instruction set compatible with 
the PIC16C5X family. All instructions are single 
cycle, except for program branches which take 
two cycles.

9­54 
Processor  Description 
TSK3000  The TSK3000A is a 32­bit, Wishbone­ 
compatible, RISC processor. Most instructions 
are 32­bits wide and execute in a single clock 
cycle. In addition to fast register access, the 
TSK3000A features a user­definable amount of 
zero­wait state block RAM, with true dual­port 
access. 
The TSK3000A has been specifically designed 
to simplify the development of 32­bit systems 
targeted for FPGA implementation and to allow 
the migration of existing 8­bit systems to the 32­ 
bit domain with relative ease and low­risk. As a 
result, complications typically associated with 32­ 
bit system design, such as complex memory 
management, are minimized. 
Actel – COREMP7  Altium Designer's CoreMP7 component is a 32­ 
bit Wishbone­compatible RISC processor, for 
use in FPGA designs targeting supported Actel 
Fusion or ProASIC®3 families of physical FPGA 
devices. 
Although placed in an Altium Designer­based 
FPGA project as a CoreMP7, this is essentially a 
Wishbone­compliant wrapper that allows use of 
Actel's corresponding 'soft' CoreMP7 processor 
core. 
Similar to (and fully compatible with) the 
ARM7TDMI­S™ core processor, the CoreMP7 is 
an implementation of the ARM® architecture 
v4T. This RISC architecture supports both the 
32­bit ARM instruction set, as well as the 16­bit 
Thumb instruction set. 
Altera – NIOS II  The Altera® Nios® II is a fully functional, 32­bit 
load/store, Wishbone­compliant processor that 
employs RISC architecture with a streamlined 
set of single word instructions.  Nios® II is for 
use in FPGA designs targeting supported Altera 
families of physical FPGA devices. 
The processor comes in three flavors – fast, 
standard and economy. Although each is placed 
in an Altium Designer­based FPGA project as a 
Nios II, this is essentially a Wishbone­compliant 
wrapper that allows use of Altera's 
corresponding 'soft' Nios II processor core. 
All instructions are 32­bits wide and most 
execute in a single clock cycle (standard and fast 
variants only). In addition to fast register access, 
the Nios II features a user­definable amount of 
zero­wait state block RAM, with true dual­port 
access. 
The Nios II core must be licensed from Altera – 
and must be purchased separately.

9­55 
Processor  Description 
AMCC – PPC405CR  Altium Designer's PPC405CR component is a 
32­bit Wishbone­compatible RISC processor. 
Although placed in an Altium Designer­based 
FPGA project just like any other 32­bit processor 
component, the PPC405CR is essentially a 
Wishbone­compliant wrapper that allows 
communication with, and use of, the discrete 
PowerPC 405 processor encapsulated within the 
AMCC PPC405CR device. 
You can think of the wrapper as being the 
'means' by which to facilitate use of external 
memory and peripheral devices – defined within 
an FPGA – with the discrete processor. 
Most instructions are 32­bits wide and execute in 
a single clock cycle. In addition to fast register 
access, the PPC405CR features a user­ 
definable amount of zero­wait state block RAM, 
with true dual­port access. 
NXP ­  LPC2100  The NXP LPCxxx family of Microprocessors are 
32­bit ARM­based hard processor devices 
available from NXP (founded by Phillips). 
Altium Designer includes full application 
development and debugging tools for these 
devices though there is no Wishbone wrapper for 
use in conjunction with an FPGA design.  These 
devices, when connected, will appear in the 
hard­devices chain however they would not be 
included as a component in your FPGA 
schematic. 
Additional information and datasheets for these 
devices can be found online at 
http://www.nxp.com/ . 
Sharp ­ Bluestreak  Altium Designer's ARM720T_LH79520 
component is a 32­bit Wishbone­compatible 
RISC processor. 
Although placed in an Altium Designer­based 
FPGA project just like any other 32­bit processor 
component, the ARM720T_LH79520 is 
essentially a Wishbone­compliant wrapper that 
allows communication with, and use of, the 
discrete ARM720T processor encapsulated 
within the Sharp Bluestreak LH79520 device. 
This discrete Sharp Bluestreak® LH79520 is a 
fully integrated 32­bit System­on­Chip (SoC), 
based on an ARM720T 32­bit RISC processor 
core. 
You can think of the wrapper as being the 
'means' by which to facilitate use of external 
memory and peripheral devices – defined within 
an FPGA – with the discrete processor.

9­56 
Processor  Description 
Xilinx ­ Microblaze  The Xilinx® MicroBlaze™ is a fully functional, 
32­bit load/store, Wishbone­compliant processor 
that employs RISC architecture with a 
streamlined set of single word instructions. 
MicroBlaze can be used only with FPGA designs 
targeting supported Xilinx Spartan® or Virtex® 
families of physical FPGA devices. 
Although placed in an Altium Designer­based 
FPGA project as a MicroBlaze, this is essentially 
a Wishbone­compliant wrapper that allows use 
of the 'soft' MicroBlaze processor core. 
All instructions are 32­bits wide and most 
execute in a single clock cycle. In addition to fast 
register access, the MicroBlaze features a user­ 
definable amount of zero­wait state block RAM, 
with true dual­port access. The MicroBlaze core 
is licensed as part of the Xilinx EDK (Embedded 
Development Kit) – and must be purchased 
separately. 
Xilinx – PPC405A  The PPC405A is a fully functional, 32­bit 
load/store, Wishbone­compliant processor that 
employs RISC architecture with a streamlined 
set of single word instructions. 
As the PPC405 is immersed in a Virtex­II Pro 
device, only designs targeting this device may 
make use of the processor. Should you wish the 
freedom of a device and FPGA Vendor­ 
independent 32­bit system hardware platform, 
use the available TSK3000A 32­bit RISC 
processor. 
Although placed in an Altium Designer­based 
FPGA project as a PPC405A, this is essentially a 
Wishbone­compliant wrapper that allows use of 
the 'hard' PowerPC® (PPC405) processor core 
immersed in the target physical device. 
Most instructions are 32­bits wide and execute in 
a single clock cycle. In addition to fast register 
access, the PPC405A features a user­definable 
amount of zero­wait state block RAM, with true 
dual­port access.

9­57 
9.5.2  Processor 

Figure 29. The Processor options in the Project Options dialog 

The Processor build option has settings for Processor Definition used to specify a particular 
derivative of a given processor family (for example, Nios IIe, Nios IIf, Nios IIs) if available; as 
well as processor­specific options to include such things as a multiply / divide unit, floating 
point unit, etc. depending on the capability of a given processor. 

Some processor families also include optional control of the Startup Code.  The Startup code 
is used to initialize the processor and any pre­initialized variables before execution begins at 
void main(void).  Though the defaults are generally acceptable for the majority of 
projects, should you ever choose not to include the default startup code produced by the 
compiler you can disable this option.  You will then have to assume the responsibility of 
handling the reset interrupt, initializing memory variables, and passing control to the main 
function in the C source code. 

9.5.3  C Compiler 
The Compiler is functionally responsible for parsing the high­level C source commands and 
reducing them to atomic operations that can be easily mapped onto the target processor’s 
instruction set.  This process involves a number of phases including (but not limited to): 

1.  Preprocessing 
2.  High­level Optimization 
3.  Instruction selection 
4.  Peephole Optimization / Instruction Scheduling 
5.  Register Allocation 
6.  Low­level Optimization

9­58 
Due to the vast variation in requirements and optimization goals, it is not possible to have a 
“one setting suits all” compiler.  Subsequently a number of compiler options are made visible 
to the user so that the compilation process can be tuned to the specific application.  Below is 
a short list of only a few of these options.  For more detailed descriptions of these and more 
build­related commands, refer to the Embedded Tools Reference for the selected processor 
family located in the software Help directory or on the Altium website. 

Figure 30. The Compiler options in the Project Options dialog 

9.5.3.1  Preprocessing 
This section is helpful if it is necessary to define preprocessor macros that will direct 
conditional compilation in the source.  For example you may wish to declare a macro called 
DEBUG_MODE and use conditional compilation in your source code depending on whether this 
macro was defined: 

#ifdef DEBUG_MODE 
do something... 
#else 
do normal processing... 
#endif 

This section can also be helpful when changing something across the entire project. 

9.5.3.2  Optimization 
The TASKING C compiler offers five preconfigured optimization levels as well as a custom 
level.  At each level a specific set of optimizations is enabled.  Generally the trade­off is 
between speed and size.  Code can be optimized for either speed or size however that code 
optimized for speed is generally larger, whereas code optimized for size is generally slower. 
Applications that have not been optimized will generally execute more quickly; however the 
amount of space required in memory will be more substantial.  There is also the trade­off with 
respect to the ability to debug.  Highly optimized code is difficult to debug as the relationship 
between the source code and the compiled code becomes progressively more difficult to 
understand.

9­59 
It is suggested to begin with the fewest possible optimizations enabled and after ensuring the 
code is correct, progressively optimize your application until achieving the ideal relationship 
between speed and size.

· Level 0: No optimizations are performed. The compiler tries to achieve a 1:1 resemblance 
between source code and compiled code. Expressions are evaluated in the order written in 
the source code, associative and commutative properties are not used.  Compiled code 
will generally run faster at this level of optimization and performance will decrease as the 
software is further optimized.
· Level 1: Enables optimizations that do not affect the debug­ability of the source code. Use 
this level when you are developing/debugging new source code.
· Level 2: Enables more aggressive optimizations to reduce the memory footprint and/or 
execution time. The debugger can handle this code but the relationship between source 
code and generated instructions may be hard to understand. Use this level for those 
modules that are already debugged. This is the default optimization level.
· Level 3: Enables aggressive global optimization techniques. The relationship between 
source code and generated instructions can be very hard to understand. Use this level 
when your program does not fit in the memory provided by your system.
· Level 4:  Fully optimize for size.  This is the most aggressive level of optimization and 
should only be used once the application has been completely debugged.  The application 
may execute more slowly however its memory footprint can be far less substantial.
· Custom level: you can enable/disable specific optimizations. 

9.5.3.3  Language 
Default settings are usually adequate however occasionally you may wish to build code that is 
pre ISO C 99 compatible and will therefore need the options contained in this panel.  This 
panel also contains options to allow use of GNU C extensions if desired. 

9.5.3.4  Debug information 
In general it is helpful to always generate debug information unless building for a final 
production release where debug information would be superfluous.  You might also disable 
this option if you intend to make your code available as a library and would prefer to protect 
your IP. 

9.5.3.5  Floating point 
In general the default settings are acceptable though the option to Use single precision 
floating­point only can affect both the size and execution speed. When checked, variables 
of the type ‘double’ will be treated as ‘float’.  Select this option in the event you do not require 
double­precision. 

9.5.3.6  Diagnostics 
This section controls how compilation warnings are reported.  In some cases it may be 
desirable to suppress specific warnings if they are creating too much ‘noise’ in the Messages 
Panel. 

9.5.3.7  MISRA C & MISRA C Rules 
The Motor Industry Software Reliability Association (MISRA) is in existence “To provide 
assistance to the automotive industry in the application and creation within vehicle systems of 
safe and reliable software.”  Through extensive consultation within the automotive industry, 
MISRA has completed the development of guidelines specifically aimed at the use of the C 
language in safety related systems.  These guidelines primarily identify those aspects of the C 
language that should be avoided in safety­related systems, along with other

9­60 
recommendations on how other features of the language should be used. It is anticipated that 
the guidelines will be adopted for embedded C programming throughout the automotive 
industry. 
Altium Designer includes a number of compilation options that can flag as a warning code that 
does not comply with MISRA recommendations. 

9.5.3.8  Miscellaneous 
Use this section to pass any compiler flags or settings that have not been covered in the 
previous panels.  The Options String at the base of the compiler settings panel provides an 
indication of the options that will be passed to the C compiler.  Further information about each 
individual setting can be found in GU0105 Embedded Tools Users Guide.pdf or via the help 
system under Embedded Software Development » Embedded Tools Options Reference 
» Compiler Options. 

9.5.4  Assembler 
The assembler converts hand­written or compiler­generated assembly language programs 
into machine language, using the IEEE­695 object format.  These files serve as input for the 
linker. 

9.5.4.1  Phases of the assembly process 
1.  Preprocess directives 
2.  Check syntax of instructions 
3.  Instruction grouping and reordering 
4.  Optimization (instruction size and jumps to branches) 
5.  Generation of the relocatable object file and optionally a list file 

The Project Options… dialogue box contains a number of assembler options.  The 
subsections of the assembler options allow for additional control over the assembler in much 
the same way that the previously mentioned compiler options do. 
The default options are generally sufficient for most applications. However, should you find it 
necessary to tune the assembler; further information can be found in the Embedded Tools 
Reference for the target processor available under the help system or on the Altium website.

9­61 
Figure 31. The Assembler options in the Project Options dialog 

9.5.5  Linker 
The linker combines and transforms relocatable object files (.obj) into a single absolute 
object file. This process consists of two phases: the linking phase and the locating phase. 
In the first phase the linker combines the supplied relocatable object files (.obj files, 
generated by the assembler) and libraries into a single relocatable object file. In the second 
phase, the linker assigns absolute addresses to the object file so it can actually be loaded into 
a target. 
The linker can simultaneously link and locate all programs for all cores available on a target 
board. The target board may be of arbitrary complexity. A simple target board may contain 
one standard processor with some external memory that executes one task. A complex target 
board may contain multiple standard processors and DSPs combined with configurable IP­ 
cores loaded in an FPGA. Each core may execute a different program, and external memory 
may be shared by multiple cores. 
Most linker options can be controlled via the project options dialog but some options are only 
available as command line switches.  The default options are generally sufficient for most 
applications however should you find it necessary to tune the linker then further information 
can be found in the Embedded Tools Reference for the target processor available under the 
help system or on the Altium website.

9­62 
Figure 32. The Linker options in the Project Options dialog 

9.5.6  Device Software Framework 
Altium Designer’s Device Software Framework (DSF) has been designed to dramatically 
simplify embedded application development in the Altium Designer environment. 

The Device Software Framework delivers:

· A Low Level Peripheral Interface (LLPI) layer, with tight integration between the 
FPGA peripherals and their driver code.
· A Processor Abstraction Layer (PAL) greatly simplifies the portability of your 
embedded application across all target processors, both embedded and discrete 32­ 
bit, supported by Altium Designer.
· While the DSF ‘abstracts away’ most of the physical layer from the embedded 
application development process, you continue to have direct access to the 
processor’s interrupt system. 

Included in the Device Software Framework are the low­level drivers required to support the 
peripheral cores bundled with Altium Designer.  The availability of the Processor Abstraction 
Layer ensures that when utilizing these peripherals, it is possible to change 32­bit processors 
with limited impact to the overall system. 

Device Software Framework source files (the low level drivers supplied with Altium Designer) 
are stored in the application directory under C:\Program Files\Altium Designer 
6\System\Tasking\dsf\ 

Here you will find all of the C source files as well as their associated header files.  Though 
these files will not be copied to the project upon compile, they will be included if the option to 
utilize the Device Software Framework is enabled.

9­63 
To use the Device Software Framework and the associated driver files, you must include the 
following lines in a C source file within your embedded project: 

#define DSF_IMPLEMENT 
#include "dsf_system.h" 

This will enable the Low Level Peripheral Interface.  To enable the Processor Abstraction 
Layer you must check the embedded project option Use Processor Abstraction Layer in 
project.  This will make the design more easily portable between processors as this will 
abstract the interface of the processor from the peripherals you include in the design. 

Figure 33 highlights some of the differences between traditional embedded systems and 
those which utilize DSF. 

Figure 33. Differences between a traditional embedded application and Device Software Framework 

The DSF allows the embedded application to be portable between processors, instead of 
being tightly coupled to the hardware as it is in the traditional approach.

9­64 
Figure 34. The Device Software Framework options in the Project Options dialog 

9.5.7  POSIX Configuration 
Altium Designer includes support for a POSIX compliant Minimal­Real Time kernel, 
supporting the POSIX.13 PSE51 Real­Time profile.  This means that the implementation 
supports the required interfaces referenced in the appropriate standardized profile. These 
interfaces support the functional behavior and any additional constraints or options as 
described in the appropriate base standard. 

To utilize the POSIX kernel, check the option Compile project as a POSIX application and 
select the Units of Functionality, Option Requirements, and Implementation Defined 
Constants required by your application. 

Figure 35. The POSIX options in the Project Options dialog

9­65 
9.6  Attaching an embedded project to an FPGA project 
Creating a link between the softcore and its 
associated embedded code ensures that 
correct code / processor coupling is made.  It 
also ensures that subsequent project builds 
incorporate all hardware and software changes 
that have been made. 

The process of linking an FPGA Project to its 
associated embedded code first requires that 
both projects are open together.  Figure 36 
shows two projects open together prior to being 
linked.  These two projects are not bound in 
any way. 

To link the Embedded Project to the FPGA 
Project we must utilize the Structure Editor.  Figure 36. Unlinked projects 

File View  Structure Editor 

Figure 37. Linked projects (File View).  Figure 38. Linked projects (Structure Editor). 

In the File View, files are grouped primarily  In the Structure Editor, the hierarchical linkage 
according to which project they are a part of  between projects is shown – i.e. above we see 
and secondarily according to the file type –  that the embedded project has been linked to 
schematic, PCB, settings, etc.  U3 (the TSK3000A core) in the FPGA project.

9­66 
9.6.1  Linking the projects 
Linkage between projects is created 
and broken using drag­and­drop.  By 
click­and­holding the left mouse 
button on a sub­project, all possible 
drop locations (valid linkage points) 
will highlight in blue and the sub­ 
project can be drag­and­dropped onto 
the parent project to create the link. 
To break the linkage, drag the sub­ 
project away from the parent project 
and drop it on a clear region of the 
Structure Editor. 

Alternatively you can right click on the 
processor and specify the embedded 
project using the Set Embedded 
Project menu option. 

Figure 39. Linking an embedded project to its hardware 

Figure 40.  Linking an embedded project to a processor via the schematic interface

9­67 
9.7  Exercise 13 – Linking projects 
In this exercise we will link our two projects to one another. 

1.  With both your FPGA and Embedded projects loaded in the Projects panel change to 
the Structure Editor view. 
2.  Link the two projects as described in the previous section. 
3.  Once the projects have been correctly linked return to the File View and the projects 
should appear linked. 
4.  You can try unlinking the two projects again by dragging the linked embedded project 
off of U2 in the structure editor. 
5.  Save your work. 

9.8  Exercise 14 – Building our design 
In this section we will configure our design for the build process and subsequently build both 
our FPGA project and embedded projects, programming the Spartan 3 FPGA on the Desktop 
NanoBoard. 

1.  Auto Configure the FPGA project. 
2.  Right Click the FPGA Project in the Projects panel and Select Add New to 
Project»Constraint File to add a new blank Constraint file to the project. 
3.  In the constraint file, add a new port constraint that constraints CLK_BRD with a 
constraint kind of FPGA_CLOCK_FREQUENCY with a value of 50MHz. 

4.  Make sure your Desktop NanoBoard is connected to your PC and powered on. 
5.  Ensure that the Live checkbox is checked.  You should see a picture of the Desktop 
NanoBoard in the upper region of the display and an icon of the Spartan3 FPGA in the 
middle region. 
6.  In the drop down list just below the Spartan3 icon, ensure that the 
CHC_image_rotation / NBD2DSK01_07_DB30_04 project / configuration pair is 
selected. 
7.  Click once on the words Program FPGA to begin the build process. 
8.  As the build process progresses, the colored indicator from each stage will turn yellow 
while it is processing and then green when completed successfully.  The process of 
building the design may take several minutes to complete.  You can observe the 
progress of the build from the Messages and Output panels which can be accessed 
from the System Panel tab in the lower right section of the Altium Designer workspace 
(see Figure 41).

9­68 
Figure 41.  Building the FPGA design 

9.  If any errors occur you will need to rectify them before you can proceed.  Try to locate 
the source of the error by retracing your steps through the instructions of the tutorial. 
10.  A summary dialog will be displayed once the design has been built and downloaded 
successfully.  Click OK to close this dialog. 
Once the FPGA design has 
been downloaded to the 
Desktop NanoBoard, you 
should notice that the status 
of the TSK3000 processor 
has changed from Missing 
to Running.

9­69 
11.  At this stage our design has been downloaded to the 
NanoBoard and the LEDs should display a binary 
pattern consistent with the hex value 0x55 that we 
had specified in our source code (left to right the 
LEDs should read 01010101b  or 85d with the LSB 
being the right­most bit n the row of LEDs). 

9.9  Exercise 15 – Updating our software Live 
In this exercise we will make changes to the software running on the host processor inside 
the FPGA on the NanoBoard, then update these software changes to the processor as it 
executes in system, in real­time. 

1.  With the FPGA and Processor successfully programmed on our NanoBoard, open the 
main.C file in the EmbeddedProject.PrjEmb file. 
2.  Modify the function  main  to read: 
void main(void) 

LEDS = 0xFF; 

3.  Updating the software running on the NanoBoard does not require us to reprogram the 
FPGA, only to update the software on running on the processor. 
Press the Compile and Download button  in the toolbar at the top of the screen to 
recompile the software and update your changes to the processor running on the 
FPGA. 

This should change the state of the LEDs on the NanoBoard such that they appear to all be 
on.

9­70 
10  Updating the Design to Display Video 
In this section we will modify the software to read video from the composite video input and 
output that video on the touch screen display.  We will then explore some of the software 
debug capabilities found in the Altium Designer environment and employ our virtual 
instruments to test our design Live, in­system. 

10.1  Defining Sections 
It is sometimes useful to define memory sections in embedded software.  Sections are a 
reference to a specific location in memory that can be passed to the locator to control the way 
that a program is located or uses memory. 

Sections are created from the Project Options dialog for the embedded project.   To create a 
section, launch the Project Options dialog and select the tab Sections/Reserved Areas. 
The Add Section button is used to add a new section and will launch the Section dialog. 
The Add Reserved Areas button is used to create new reserved areas that or areas that will 
not be used during the Linking and Locating process. 

Figure 42.  Creating sections for the locator

10­71 
The following table details the various options in the Section dialog. 

Option  Description 

Name  The name field is used as a label or reference to the 
section defined in the source code. 

Location  This is the processor’s view of where the section appears 
in the address space.  The size of the section is 
automatically allocated. 
The location can be specified as a decimal or hex value, 
or a memory. 

Locate Static Data  Used to locate the ROM initialization data for the section. 
Uncheck to locate the section itself. 

Fill Bit Pattern  Used to initialize the empty spaces at the end of a 
section as a result of an MAU alignment.  If the section is 
in ROM, leaving this blank will fill the section with zeros. 
If it is in RAM, the spaces are not initialized. 
Dependencies  If checked, any dependencies of the section will also be 
located by this section layout directive. 
Notes  Used to add any user notes that might help explain or 
describe the section.

10.2  Exercise 16 – Updating our software Live 
In this exercise we will create two sections, the names of which will be labels that can then be 
used as a qualifier when we create an array for the video capture and video display buffers. 
The advantage to Sections is in the finer control it gives over the way in which a program is 
Located and uses memory.  Sections can be created and even nested to make an almost 
‘hierarchical’ partitioning of a design’s memory resources possible. 

1.  Right­click the embedded project in the Projects panel and select Project >> Project 
Options. 
2.  Select the Configure Memory tab and observe that entries for XRAM1 (the Video 
Capture side of our design) and XRAM2 (the Video Display side of our design) exist. 
3.  Select the Sections/Reserved Areas tab of the Options for Embedded Project 
CHC_Image_Rotation.PrjEmb dialog. 
4.  Click the Add Section button to launch the Section dialog. 
5.  In the Section dialog box: 
a.  Set the Name to .bss.video 
b.  Set the Location to mem:XRAM1 
6.  Click OK to close the Section dialog box and observe that the new memory section has 
been added. 
7.  Click the Add Section button again 
8.  In the Section dialog box: 
a.  Set the Name to .bss.tft 
b.  Set the Location to mem:XRAM2 
9.  Click OK to close the Options for Embedded Project CHC_Image_Rotation.PrjEmb 
dialog. 

10­72 
10.3  Exercise 17 – Updating our Software to Capture Video 
In this exercise we will update our application code with the software required to capture and 
display video.  Utilizing the Device Software Framework, much of the process of initialization 
and the low­level interaction with the hardware will be simplified.  We instead will 
communicate with the hardware through its Low Level Peripheral Interface layer we’d 
discussed earlier.  This dramatically reduces the amount of effort required in getting our 
system off the ground. 

1.  Open main.C and remove any existing lines of code that might be in the file. 
2.  Launch the Snippets panel under System»Snippets using the buttons along the lower 
right corner of the workspace. 
3.  Locate and Add the Snippet “Video_Pass_Through_1” to main.C.  This contains the 
#defines that specify the basic characteristics of the video including its height, width, 
screen resolution (both X and Y) and the attributes required to properly center the 
image on the screen. 
This section also contains #pragmas for both the video and display memories, used to 
define the size of the Sections required by these two buffers. 
4.  Return to the Snippets panel and add the Snippet “Video_Pass_Through_2” to main.C 
(the position of the cursor in the text editor will determine the point at which the Snippet 
is inserted). 
5.  If the code appears unformatted, select Tools»Format Source Code and it will be 
formatted automatically to match your formatting standards specified under 
Tools»Formatting Options… 
Examine the source code in the function void main(void).  The code is quite simple 
really. 
6.  Holding the Ctrl key on your keyboard, 
hover your cursor over the various 
function names listed in the 
initialization sections.  You will see the 
cursor change to a small hand. 
7.  Clicking on the name of one of these 
functions whilst in this mode will open 
the source Device Software 
Framework source file containing the 
function being referenced.  We are 
essentially calling a series of DSF 
functions and passing them 
parameters that simplify the 
initialization and control of the 
behavior of the peripherals. 
8.  Rebuild and download your source code by hitting the  button in the toolbar along 
the top of the workspace.  This will automatically save the source file at the same time. 

Video should now display from your camera on the screen on your NanoBoard.  Try moving 
the camera and have a look around.

10­73 
10.4  Utilizing the Virtual Instruments 
To achieve an understanding of how our design might function in its final implementation – i.e. the 
“real­world,” Altium Designer provides a host of Virtual Instruments that can, utilizing FPGA­ 
resources, be used to test and debug our system live.  A major advantage of this approach is that 
the interaction is with the real hardware and not a software simulator.  This allows us to find and 
correct logic errors, as well as issues with the software, on the physical hardware, in real­time. 

Further to this, utilizing this methodology and the inherently reprogrammable nature of the 
FPGA platform, it is easy to see how we might later use instrumentation in our design, even 
after it has been fully implemented, to test our design, in­system, and possibly even other 
components of our system. 

10.5  Using instruments to control our design 
The instruments we will use will provide us a method with which to control our design and 
afford us an unprecedented view into the signals inside our device, in real­time.  Below is a 
list of the instruments we will utilize for this next section: 

Instrument  Role 
Configurable Digital IO  We will utilize the Configurable Digital IO 
Configurable Digital IO 
component to control the rotation and scaling of our 
InLEDs[7..0]  Rot[7..0]  image on the TFT display. 
SpareOutB[7..0]  Zoom[7..0] 
SpareOutC[7..0]  Flags[7..0] 
SpareOutD[7..0] 

Logic Analyzer 1k x 8  We will use the Logic analyzer to monitor the 
U16  signals coming out of the Wishbone Port IO 
Logic Analyser 1k x 8  component; specifically those being sent to the 
CLK  STATUS  LEDs on the NanoBoard. 
CLK_CAP 
EXT_TRIGGER 

Measure 
LEDS[7..0] 
LAX 

Frequency Generator  We will use the Frequency Generator to create a 
time base for our Logic Analyzer. 
U19 
TIMEBASE  FREQ 

Frequency Generator 
CLKGEN 

Frequency Counter  We will use the Frequency counter to watch the 
U18 
time base generated by our Frequency Generator 
and the signal being output to the LEDs.
FREQA 
FREQB 

TIMEBASE 

Frequency Counter 
FRQCNT2 

10­74 
10.6  Exercise 18 – Updating the Wishbone Port IO 
Prior to adding the instruments, we need to make a modification to our design.  Specifically, 
we need add a few additional IO ports to the Wishbone Port IO component.  These IO ports 
will be used to interface the instruments to our design. 
In this exercise we will update our Wishbone Port IO the Peripheral Interconnect components. 
These ports will be used by the host processor to read the Rotation and Scaling values from 
the Digital IO instrument.  We will also include some input Flags that our software can rigger 
off of.  Additional outputs will also be used to optionally display the rotation, scaling, and flag 
values as binary values on the Digital I/O component (thus giving us some visibility into just 
what our settings are). 

1.  Double­click the Configurable Wishbone Port I/O component U14 and hit the Configure 
button in the Component Properties dialog or right­click U14 in the schematic and 
select Configure U14 (WB_PRTIO)…. 
2.  Change the Port Count value to 4.  This will give us 4 input ports, each 8 bits wide, 
and 4 output ports, also 8 bits wide. 
3.  We now need to update our Wishbone Interconnect component to be able to address 
each of these 4 different I/O ports.  To do so double­click the Wishbone Interconnect 
component U1 and hit the Configure button in the Component Properties dialog or 
right­click U1 in the schematic and select Configure U1 (WB_INTERCON)…. 
4.  Highlight GPIO in the list of peripherals and select the Edit Device button at the bottom. 
5.  Edit the Address Bus Width to 2 Bits – Range = 4.  This will allow us to address each 
of the 4 I/O ports from the processor. 
6.  A new address pin will appear on the Wishbone Interconnect and the Wishbone Port 
I/O component (s2_ADR_O[1..0] and ADR_I[1..0] respectively).  Using Place»Bus, wire 
these two pins to one another. 
7.  Additional pins have also been added to the left of the Wishbone Port IO component. 
Wire these pins and verify the wiring matches the image below. 

Figure 43. Placing and wiring the wishbone port IO. 

Now with the Wishbone Port I/O and Wishbone Interconnect components updated we can 
begin the process of adding the Virtual Instruments to our design.  In the following exercises 
we will add each of the instruments we intend to use.

10­75 
10.7  Exercise 19 – Adding the Virtual Instruments 
1.  Go to the Libraries panel and place the component DIGTAL_IO.  Designate this 
component U11. 
2.  Right click this component and select Configure U11 (DIGITAL_IO)…  Configure the 
component as it appears in Figure 44. 

Figure 44. Digital IO component configured for the design 

3.  Wire the component as indicated in Figure 45.  This will tie together the signals on our 
Wishbone Port IO device and the Configurable Digital IO instrument. 

Configurable Digital IO 
LEDs[7..0]  Rotation[7..0] 
InLEDs[7..0]  Rot[7..0] 
SpareOutB[7..0]  Zoom[7..0] 
SpareOutB[7..0]  Zoom[7..0] 
SpareOutC[7..0]  Flags[7..0] 
SpareOutC[7..0]  Flags[7..0] 
SpareOutD[7..0] 
SpareOutD[7..0] 

Figure 45. Wiring for the configurable digital IO 

4.  Place the clock generator component CLKGEN, designating this component U19 
5.  Place the frequency counter component FRQCNT and designate this component U18 
6.  Wire both components as they appear in Figure 46. 
U18 
U19  LEDs0 
FREQA 
CLK  LAX_CLK 
TIMEBASE  FREQ  FREQB 
CLK 
Frequency Generator  TIMEBASE 
CLKGEN 
Frequency Counter 
FRQCNT2 

Figure 45. Wiring for the frequency generator and frequency counter instruments

10­76 
7.  Place the logic analyzer component LAX, designating this component U42. 
8.  Configure the LAX with one signal set Measure, and a single signal LEDS[7..0] as seen 
in Figure 46. 

Figure 46. LAX configured to capture input from the LEDS 

9.  Wire the LAX as it appears in Figure 47. 

U16 
Logic Analyser 1k x 8 
CLK 
CLK  STATUS 
LAX_CLK 
CLK_CAP 
LEDs0 
EXT_TRIGGER 

Measure 
LEDs[7..0] 
LEDS[7..0] 
LAX 

Figure 47. Wiring for the configurable LAX

10­77 
10.8  Exercise 20 ­ Rebuilding the project with instruments 
1.  Make sure your Desktop NanoBoard is connected to your PC and powered on. 
2.  Select View >> Devices View or click on the Devices View icon  in the toolbar. 
3.  Ensure that the Live checkbox is checked.  You should see a picture of the Desktop 
NanoBoard in the upper region of the display and an icon of the Spartan3 FPGA in the 
middle region. 
4.  In the drop down list just below the Spartan3 icon, ensure that the 
CHC_image_rotation / NBD2DSK01_07_DB30_04 project / configuration pair is 
selected. 
5.  Locate the Compile, Synthesize, Build, Program FPGA buttons running left to right 
just below the Desktop NanoBoard icon.  Click once on the words Program FPGA to 
begin the build process. 

10.9  Updating our embedded project to use the instruments 
To make use of the virtual instruments we will require some changes to the application code 
in our embedded project.  This includes a piece of software that makes zooming and scaling 
dependent on the two sliders we’ve added using our Configurable Digital IO Instrument.  In 
this section we will modify our software and embedded project to get the video working with 
our instruments. 

10.10  Exercise 21 – Adding Additional Source Files 
To further simplify our embedded project we will do some simple partitioning.  This makes 
the source files easier to read and manage and makes our files far more reusable. 

1.  Right click the embedded project EmbeddedProject.PrjEmb and select Add New to 
Project.  Add a new H File. 
2.  Add the contents of the snippet Spinning_Video_Defines_Header  to this source 
file. 
3.  Save the file as defines.h. 
4.  Right click the embedded project EmbeddedProject.PrjEmb and select Add New to 
Project.  Add a new H File. 
5.  Add the contents of the snippet Spinning_Video_DSF_Header to this source file. 
6.  Save the file as dsf.h. 
7.  Right click the embedded project EmbeddedProject.PrjEmb and select Add New to 
Project.  Add a new C File. 
8.  Add the contents of the snippet Spinning_Video_DSF_SourceFile to this source 
file. 
9.  Save the file as dsf.c. 

10.11  Exercise 22 – Updating main.c 
In this exercise we will update main.c to include the application code necessary to respond 
to our inputs and rotate and scale our video. 

1.  Open the main.c source file in the project EmbeddedProject.PrjEmb 
2.  Select and delete all of the source code located in this file. 
3.  Add the contents of the snippet Spinning_Video_main_SourceFile  to this source 
file. 
4.  Save the file as main.c 
5.  Save the embedded project EmbeddedProject.PrjEmb by right clicking the project 
document in the Projects panel and selecting Save Project.

10­78 
6.  Return to main.c and press the Compile and Download button  in the toolbar at 
the top of the screen to recompile the software and update your changes to the 
processor running on the FPGA. 
7.  With the aid of your instructor, have a look at the source code.  The bulk of the 
capability rests in the main.C file. 

10.12  Exercise 23 – Controlling our design with instruments 
In this exercise we will familiarize ourselves with the interface to the Digital IO Virtual 
Instrument. 
1.  Switch to the Devices View under View»Devices Views or by hitting the  button in 
the toolbar at the top of the screen Select and delete all of the source code located in 
this file. 
2.  The soft nexus JTAG chain should display all of the instruments we’ve added to our 
design, as well as the host processor. 

Figure 48. Soft devices chain shows the instruments in our design 

3.  Right click the U11 DIGITAL_IO and select Instrument to launch the Instrument Rack 
for this soft device. 

Figure 49. Instrument rack for the configurable Digital IO 

The INPUTS region of the instrument panel 
allows you to monitor the digital signals that 
have been wired to the input channels of the 
DIGITAL_IO instrument. 

4.  Click on the Options button, at the bottom 
left of the panel, to access the Digital I/O 
Module – Options dialog.  The display for 
each input is refreshed (updated) in accordance with the value specified in the Update 
Display From Core Every field of this dialog. 
5.  Move the slider Rot[7..0] to the right and observe the image rotating on the TFT. 
6.  Move the slider Zoom[7..0] to the right and observe the image scaling on the TFT.

10­79 
7.  Recall in our source code we has created 2 conditions for Flags[7..0].  The first 
condition was in the form of an If…Else statement that read: 

if (Flags & 0x01) 
alpha += Rotation; 
else 
alpha =  Rotation << 1; 
alpha =  alpha >= 360 ? 0 : alpha; 

If bit 0 of the array Flags[7..0] is set, the image will continue to rotate (the variable 
Rotation  refers to the B input PBI[7..0] of our Wishbone Port IO component). 
8.  Set the right­most bit (the LSB) of Flags[7..0] to see the image on the TFT change to a 
state in which it is rotating continuously. 
9.  Recall in our source code that we had a second condition controlled by Flags[7..0], this 
time controlling our scaling of the image: 

if (Flags & 0x02) 

scale += delta * Zoom; 
if (scale > 1024) 
delta = ­ 1; 
if (scale < 256) 
delta = 1; 

else 
scale = 256 + Zoom * 3; 

Under this condition, the second bit of Flags[7..0] will cause the scaling to continue to 
both increase and decrease. 

10.  Set the second bit of Flags[7..0] and notice the image changes to both increase and 
decrease in a continuous motion. 
11.  Time permitting, experiment with some of the other instruments in the design.

10­80 
11  Real­time Debugging of a Processor 
Altium Designer includes a range of tools to debug our soft processor.  This includes a more 
traditional simulation environment; as well as support for debugging real software, on real 
hardware, in real­time.  It is this capability that coupled with the Virtual Instruments, sets 
Altium Designer apart. 

In this section we will discuss some of the software debugging tools available to you in Altium 
Designer. 

11.1  On­Chip Debugging 
Each of the microprocessor / microcontroller cores supplied with Altium Designer include 
support for On Chip Debugging (OCD).  The 8­bit microcontrollers will utilize a separate 
schematic symbol with an ‘_D’ appended to the schematic symbol name to distinguish the 
OCD and non­OCD versions of the component.  Whereas the 32­bit processors contain an 
option in their respective configuration dialogs to include On Chip Debugging resources. 
The OCD system is necessary if you wish to make use of Altium Designer’s live debugging 
features.  One notable difference between the two variations of microprocessors / 
microcontrollers is the existence of program memory write resources on the OCD version. 
This is necessary since the debugger requires write access to program memory so that it can 
place breakpoints in program memory when breaking or stepping through code.  Thus when 
using the OCD version, program memory must be comprised of read/write memory.  In 
general it is advisable to use the OCD version during development and switch back to the 
non­OCD version for production. 

11.2  A word about simulation 
In general, it is desirable to interact with real hardware when debugging rather than 
performing simulations only.  The presence of the NanoBoard means that most designs can 
be debugged in real hardware, i.e. LiveDesign, however there may be the odd occasion when 
it is necessary to simulate a design. 
The Altium Designer development environment supports full simulation based debugging as 
well as LiveDesign using real hardware; the interface is identical.  Switching between 
LiveDesign and Simulation is achieved by changing the debugger mode via the Debug 
toolbar available when editing an embedded project source document, or by right clicking the 
Embedded Project in the Projects panel and selecting either Debug <processor 
designator> or Simulate. 
For our discussions we shall focus on the LiveDesign environment, as this is usually the most 
desirable mode of debugging however all that is mentioned here is applicable to the 
simulation environment also. 
The easiest way to initiate a debugging / simulation session is to right­click the embedded 
project in the Projects panel and selecting Debug or Simulate.  Of course, the Debug option is 
only available if a NanoBoard or target platform is present and powered up. 

11.2.1  The Debug menu 
Debug commands are available whenever an embedded source file is open in the main 
window.  Debug commands can be accessed via the Debug toolbar:

11­81 
…Or from the Debug menu: 
Run (F9): Run the current embedded project 
in debug mode.  After launching the 
command, execution of the code in the 
embedded software program will begin. If any 
enabled breakpoints have been setup, code 
execution will halt at these points, if 
encountered 
Run to Cursor (Ctrl+F9): Execute the 
embedded code up to the line containing the 
cursor. 
Toggle Breakpoint (F5): This command is 
used to toggle an enabled breakpoint for the 
current line.  After launching the command, 
the current line will have an enabled 
breakpoint added to it or removed from it, 
depending on whether or not an enabled 
breakpoint currently exists for that line. 
Enabled breakpoints are indicated in the code 
by a red highlight over the breakpoint line and 
a red circle with a cross in the margin. 

Disabled breakpoints are indicated in the code by a green highlight over the breakpoint line 
and a green circle with a cross in the margin. A disabled breakpoint remains defined but will 
not cause running code to halt when encountered. 
If a disabled breakpoint exists for the line and this command is used, the breakpoint will be 
removed. 
You can view a list of all breakpoints that have currently been defined in all open embedded 
project source code files, in the Breakpoints panel. 
Add Watch: This command enables you to define watch expressions for the current 
embedded source code document. A watch expression can be a single variable or an 
expression containing one or more variables and allows you to view the value of the 
expression as you step through the code. Basic mathematical operations are supported 
(e.g. a+b, a*b, c+(b­a)). 
Step Into (F7): Use this command to execute each line of the current embedded source 
code sequentially, including the individual lines of code contained within any 
procedures/functions that are called.  The next executable line of code is highlighted in blue 
and is indicated by a blue circle with an arrow in the margin. 
Step Over (F8): The same as the Step Into command except procedure/function calls are 
treated as a single line of code and executed as a single step. 
Step Into Instruction (Shift+F7): This command is used to execute each individual 
instruction at the assembly code level, in turn, including the instructions contained within 
any functions that are called. 
When the source code document is an .asm file, the next executable instruction is 
highlighted in blue and is indicated by a blue circle with an arrow in the margin. This 
command and the Step Into Source command will behave in the same way. 
When the source code is a high level language (.c file), use of this command should ideally 
be made from within one of the two disassembly views for the code ­ either the extended 
mixed source­disassembly view (accessed by clicking the Show Disassembly button on 
the debug toolbar in the source code view), or the pure disassembly view (accessed by 
clicking the Toggle Source Code button on the disassembly standard toolbar, from within 
the mixed source­disassembly view).

11­82 
In both mixed and pure disassembly views, the next executable instruction is highlighted in 
dark blue and is indicated by a dark blue circle with an arrow in the margin. 
Step Over Instruction (Shift+F8): The same as the Step Into Instruction command 
except procedure/function calls are treated as a single line of code and executed as a 
single step. 
Step Out: This command is used to step out of the current function within the embedded 
source code.  The remaining executable code within the current function will be executed 
and the execution will be passed onto the next sequential line of code after the function's 
calling statement. 
Show Disassembly: Open an intermixed source and disassembly view for the current 
embedded software project.  A new view will open as the active view in the main design 
window. This view shows a mixture of disassembled instructions and source (C) code. The 
source for all source code files in the current embedded project will be displayed. 
In this intermixed disassembly and source view, the next executable source line is 
highlighted in blue and is indicated by a blue circle with an arrow in the margin. The next 
executable disassembled instruction is highlighted in dark blue and is indicated by a dark 
blue circle with an arrow in the margin. 
Resynchronize: Use this command to synchronize the debugger execution point with the 
external hardware. 
Show Execution Point: Position the text cursor at the start of the next line of code to be 
executed. If the next executable line of code is outside of the visible area of the main 
display window, the document will be panned to bring it into view. 
Break: Halt an executing processor at the next executable line of source code. 
Reset (Ctrl+F2): Reset the executing processor currently being debugged, at any stage 
when stepping through code or after a breakpoint has been encountered, and return the 
current execution point back to the first line of executable code. 
Stop Debugging (Ctrl+F3): Terminate the current debugging session. 

11.3  Embedded control panels 
Clicking on the Embedded button of the 
workspace panels will open the list of 
embedded control panels.  Alternatively 
use the menu commands by selecting 
View » Workspace Panels » Embedded. 
Selecting F1 whilst an item within a panel 
has the focus will bring up extensive help 
on the panel’s operation. 

Figure 48. Debugger panels

11­83 
11.3.1  Breakpoints 

Figure 49. The breakpoints panel 
The Breakpoints panel provides information on all breakpoints that are currently defined ­ 
either within the open source code documents for any embedded project or in one of the 
memory address spaces associated with a processor whose embedded code is currently 
being debugged. 
The following two types of breakpoint can be defined:
· Source code breakpoint ­ applied to a particular line of code in the source document 
of an embedded software project
· Memory address breakpoint ­ specified for a particular address in a memory space 
associated with the processor on which the code is running. 
Any breakpoints that are currently defined in any open embedded project source code documents (*.C, 
*.asm), or processor memory spaces will be listed in the panel. 

11.3.2  C to Hardware 

Figure 50. C to Hardware panel.

11­84 
The C to Hardware panel provides a control panel for Altium Designer’s Application Specific 
Processor discussed later in this course.  From this panel Global Variables and Functions can 
be ‘off­loaded’ to hardware provided they meet the criteria required to instantiate the particular 
variable or function as logic.  This capability is detailed in the document GU0122 C­to­ 
Hardware Compiler User Manual.pdf 

11.3.3  Call Stack Panel 
The Call Stack panel provides information about which line of source code the debugger is 
next going to execute and which function that line of code resides in. If a sequence of function 
calls have been made to reach the current line of code, these calls will be displayed as a 'call 
stack'. 
As you step­debug your source code, the panel will show the current function you are in, the 
name of the active source document and the line of source code that the debugger has 
reached (i.e. the next line of executable code). 
When a call to another function is encountered, the panel will show that function, along with 
the values of any parameters passed into it and the next executable line of code within that 
function. As the function is called from within a function, the original function is still displayed, 
showing the line of code that will be executed when program execution passes back into it. 
A 'call stack' is effectively set up, showing the relationship between descendant function calls. 
The original function appears at the bottom of the stack, with each subsequently called 
function above it, right up to the currently entered function on the top of the stack. The current 
function is distinguished by a red arrow to its immediate left. 

Figure 51.  The Call Stack panel. 

11.3.4  Code Explorer 
The Code Explorer panel provides a visual 
summary of all identifiers (Define statements, 
Variables, Routines (functions) or Labels) that 
are used in the active source document (*.C, 
*.asm, *.h) for an embedded software project 
(*.PrjEmb). 
The information that appears in the Code 
Explorer panel depends on the type of source 
document currently active in the design editor 
window. 
Double­clicking on an entry in the panel (or 
selecting it and pressing ENTER) will jump to 
the corresponding area of code in the design 
editor window, placing the text cursor to the 
immediate left of the identifier. 
Direct filtering is available, allowing you to 
quickly jump to an entry by directly typing 
within the panel. 
To use this feature, simply click within the 
panel and type the first letter of the entry you 
Figure 52.  The code explorer panel
11­85 
wish to jump to. The first entry in the panel starting with the letter you type will become 
selected and the letter will be highlighted. 

11.3.5  Cross References 
The Cross References panel enables you to quickly locate all occurrences of a variable, 
function or procedure, within the source code documents of an embedded project. 
Information in the Cross References panel will only appear after right­clicking on an identifier 
in the source code (variable, function or procedure) and choosing the Show Cross 
References command from the subsequent pop­up menu that appears. 
Note: Cross referencing must be set up for the source code documents for this feature to be 
available.  Enable Create Cross­Reference Info under Tools»Embedded 
Preferences»Embedded System»Libraries.  Refer to the document TR0104 Altium 
Designer Panels Reference.PDF for complete details on setting up your 
preferences to support cross­referencing. 
The upper region of the panel lists instances of the selected variable, function or procedure 
name that have been found within the scope of the search. As you click on an instance, the 
lower region of the panel will show where in the source code that instance exists. 

Figure 53.  The cross references panel 

11.3.6  Debug Console 
The Debug Console panel provides a 
history of the current debug session, in 
terms of the commands issued and the 
lines of code executed. The panel also 
offers command­line debugging of the 
embedded code. 
As you debug the source code for the 
active embedded project, the panel will 
'keep track' of the debug commands as  Figure 54.  The debug panel.

11­86 
you issue them and the current execution point. For example, if you issue a Step Into 
command from the 
Debug menu or toolbar, the panel will show an entry that reflects this command (>s) followed 
by an entry that reflects the next line of code to be executed. 
The controls at the bottom of the panel allow you to drive the debug session from within the 
panel.  Simply enter the syntax for the command you wish to issue to the Debugger and either 
click the Send button or press ENTER. 
The following table contains example command­line entries that correspond to common 
debugging commands available from the Debug menu or toolbar: 

Panel Command­line  Corresponding Debug Command  Corresponding entry 


Entry  on Debug Menu  in Debug toolbar 

C  Run 

C n (where n = line  Run to Cursor 
number) 

s  Step Into 

S  Step Over 

si  Step Into Instruction 

Si  Step Over Instruction 

.dxp resync  Resynchronize 

rst  Reset 

In addition, the HALT button at the bottom right of the panel behaves the same way as the 
Break command available on the Debug menu and toolbar. 

11.3.7  Evaluate Panel 
The Evaluate panel is used to quickly determine the current value of a variable or expression 
in the active high­level source code document (*.C) currently being debugged. 
Use the field at the top­left of the panel to enter the variable or expression you wish to 
evaluate and either click the Evaluate button or press ENTER. The variable/expression string 
will appear in the main region of the panel, with the result of the evaluation appearing next to 
it, under the Value column. 
The variable/expression is not updated with respect to its value as you step­debug the code. 
You can, however, repeatedly use the Evaluate button to update the value for the entry. 
If you wish to keep a constant watch on the variable/expression, where the value is updated 
as the code executes, use the Add Watch button to add the variable/expression as a new 
watch entry to the Watches panel. 

Figure 55.  The evaluate panel

11­87 
11.3.8  Locals Panel 
The Locals panel allows you to interrogate the values of variables local to the function that 
the debugger has currently entered. You can also change the values of variables on­the­fly as 
you debug. 
As you step­debug your source code, the panel will display all local variables and passed 
parameters as they are encountered for the current function. When entering a parametric 
function, the entries will appear in the panel after execution of the calling statement. 

Figure 56.  The locals panel 

11.3.9  Registers Panel 
The Registers panel allows you to interrogate the content of registers within the core 
processor currently being debugged. You can also change the values of registers on­the­fly 
as you debug. 
For each register, the following data fields are available:
· Register ­ the name of the register
· Width ­ the size of the register (e.g. 8­bit, 16­bit, 32­bit)
· Decimal ­ the value currently stored in the register, presented in decimal format (e.g. 
30)
· Hexadecimal ­ the value currently stored in the register, presented in hexadecimal 
format (e.g. 1E)
· Binary ­ the value currently stored in the register, presented in binary format (e.g. 
0001­1110)
· Char ­ the value currently stored in the register, presented in character format (e.g. 
decimal 87 would be character W) 
The Register, Width and Char fields are non­editable. The number format fields allow for 
changing of register values as you debug.

11­88 
Figure 57.  The registers panel 

11.3.10  Watches Panel 
The Watches panel enables you to create and display a list of watch expressions, allowing 
you to keep track of variable/expression values as you single­step debug the source code of 
an embedded software project. 
The panel lists, for each watch that is added, the Expression (what to watch for) and the 
Value (the evaluation of the expression at the current line in the source code). 
A small icon to the left of the watch expression is used to indicate the status of the watch: 
­ Source code execution has entered a function or procedure where the watch 
expression is valid 
­ Source code execution has entered a function or procedure where the watch 
expression is invalid.  This state will also occur if the watch expression is not valid. 
­ Watch is disabled 

Figure 58.  The watches panel 

11.4  Instrument Rack – Nexus Debugger 
In addition to the traditional source­code level debug tools available, Altium Designer also 
includes an Instrument Rack for microprocessors / microcontrollers that gives you an 
unparalleled view of the processor’s registers, and the opcodes and instructions executing on 
the current processor.  This dialog will also allow you to pause, run, reset, and step the 
processor.

11­89 
Figure  59.  Instrument rack for soft devices 

This instrument rack is accessed by right­clicking the processor in the Devices view and 
selecting Nexus Debugger. 

Clicking on the Nexus Debugger button will access the corresponding debug panel for the 
type of processor you are using. This panel contains a greater array of debug controls, 
providing access to the internal registers, memory spaces and also shows a disassembly 
view of the embedded source code as you debug. 

Figure 60.  Nexus debugger panel 

The various memory panels available for a processor enable you to interrogate the different 
memory spaces associated to that processor, concurrently. 

The behavior of each of the available memory panels is identical, regardless of the memory 
space represented:

11­90 
· address space typically starts at 00000000h when displayed in the panel, regardless 
of where the memory physically resides in the processor's memory map
· memory space is divided into rows of 16 cells, with each cell representing an address 
in memory space and the value contained therein, in hex format. The Data column 
reflects the value at each address (in the associated row) in ASCII format
· a field is included at the top of each panel for filtering, allowing you to jump to row 
containing the specific address of interest within the represented memory space
· a refresh button at the top left of the panel enables you to manually refresh/update 
the contents of the memory space 

11.4.1  Changing the Contents of Memory 
To change the contents of an address in memory, simply click on the desired cell and type the 
new hexadecimal value as required. If the memory is writable, it will automatically be 
refreshed with the entered value. If it is read­only, the new value will be discarded and the 
memory location will remain unchanged. 
Additional editing options including options to Fill a memory with zeros, ones, or a hex value 
0xFF, as well as options to Save the memory contents to a file or Load memory contents from 
a file.  Simply right­click a memory in the dialog to view a full list of options. 

11.4.2  Defining Breakpoints in Memory 
Memory address breakpoints can be added directly to addresses from within the relevant 
panel for the required memory space. To add a breakpoint at a single address, simply right­ 
click over that address in memory and choose when the breakpoint is to be applied (on read, 
on write, on read or write).

11­91
12  C to Hardware 
In this section we will introduce you to the C to Hardware capability found in Altium Designer. 
The C­to­Hardware Compiler (CHC) compiler resembles a normal toolset (compiler, 
assembler, linker, and locator) but instead of producing a software file, it produces a hardware 
file that can be loaded onto an FPGA. 

The C­to­Hardware Compiler accepts standard untimed ISO­C source code as input and 
produces a synthesizable hardware file. The synthesis tools of Altium Designer translate this 
hardware file into an electronic circuit which can be loaded onto an FPGA along with the rest 
of the design and the software. 

In Altium Designer, the C­to­Hardware Compiler is used in combination with a traditional 
embedded compiler. This means you can write an 'ordinary' C program for a processor core. 
Using Altium Designer, you can mark which functions should be compiled to hardware. Your 
FPGA design then needs an Application Specific Processor (ASP) to hold these compiled 
hardware functions. 

When compiling and synthesizing your project (embedded software and hardware), either the 
regular C compiler or the C­to­Hardware compiler is invoked depending on whether you 
marked functions as hardware or not. 

The final result, after having compiled the application and having loaded both software and 
hardware onto an FPGA, is a system where the software and the synthesized hardware 
functions form the implementation of your original C program. The software part 'calls' 
hardware functions that perform their task far more efficiently than if they were compiled to 
software. 

12.1  What are the benefits of the C­to­Hardware Compiler? 
Virtually all C programs (or functions) can be converted to an electronic circuit by the C­to­ 
Hardware Compiler. However, the characteristics of the program determine whether the C­to­ 
Hardware Compiler can create an efficient hardware component or whether it is better to 
execute the program on a processor core. The C­to­Hardware Compiler can only create a 
small and fast electronic circuit if the C source code is parallelizable. In such a case the 
hardware executes many operations in parallel whereas a processor core would fetch and 
execute instructions sequentially. 

Graphics, signal processing and encryption algorithms translate very well into hardware and 
performance improves by orders of magnitude. For these types of algorithms FPGA 
implementations outperform high­end DSP and RISC processor cores. 
So the main benefit of the C­to­Hardware Compiler is, that it lets you design hardware 
modules to perform specific tasks by simply programming them in C. Normally this would be a 
complex and time­consuming job that would have to be performed by specialized hardware 
designers. 

12.2  Using the CHC Compiler 
For a regular embedded project, the CHC compiler will not be invoked. In this situation only 
the FPGA design is synthesized and loaded onto an FPGA together with a ready compiled 
embedded project. 
The C­to­Hardware Compiler is actually a complete toolset, including a compiler, assembler 
and linker, conceptually very similar to a regular C toolset.

12­92 
The CHC compiler is invoked when the FPGA design gives cause to do so:
· the FPGA design contains one or more Application Specific Processor (ASPs) 
components, which are able to hold the hardware equivalent of a C software function
· the configuration of the ASP­component describes that it contains at least one 
hardware compiled C function 

When building the project, based on the configuration settings of the ASPs on the schematic, 
a list of function qualifiers is generated that mark the functions to be compiled to hardware. 
This function qualifier file is submitted both to the regular embedded toolset and to the CHC 
toolset. The embedded toolset now "knows" which functions should be compiled to hardware. 
It does not compile these functions, but generates a wrapper with just enough code to call the 
hardware function, to pass any variables, and to receive the return value. The result is an 
absolute ELF object file. 

The same C sources and function qualifier file are submitted to the CHC toolset. Based on the 
function qualifier file, the CHC toolset compiles and assembles the marked C functions to 
hardware. The result is an absolute ELF object file which contains the hardware functions. 

The ELF file with the hardware functions will be translated into VHDL or Verilog by the HDL 
generator. Then it is synthesized, along with the rest of the FPGA design, resulting in a BIT 
file which can be loaded onto the FPGA. The ELF file with the software functions is already in 
its final state and will be loaded into the processor soft­core on the FPGA. 

12.3  Implementing C to Hardware in our Design 
In the following section we will prove that seeing, truly is believing.  Recall the performance of 
the rotating video.  Using the slider we saw the video scale and rotate on the TFT.  As we 
complete the following series’ of exercises we will see the performance of these two 
operations increase considerably. 

12.4  Exercise 24 – Making Room for C to Hardware 
In this exercise we will add an additional interface to our peripheral Wishbone Interconnect 
component U1.  This provides us a means for the processor to access the functions that have 
been placed in hardware. 

1.  Right click U1 in the schematic and select Configure U1 (WB_INTERCON)… 
2.  Select the Add Device button and configure this device as seen in the figure below

12­93 
Figure 60.  Adding the ASP to the wishbone interconnect 

3.  Click OK to close the Device Properties dialog. 
4.  Click OK to close the Configure U1 (Wishbone_Intercon) dialog. 
5.  Save your work. 

12.5  Exercise 25 – Adding the Application Specific Processor 
In this exercise we will add an Application Specific Processor, WB_ASP to our design.  The 
WB_ASP peripheral is used as a 'container' for C source functions that are implemented in 
hardware through use of the C­to­Hardware Compiler. 

Wired into an FPGA design just like any other peripheral, the WB_ASP enables a host 
processor access and control over hardware­compiled functions within. These functions will 
populate the WB_ASP once the design project has been compiled and synthesized. 

When a hardware function is called, the processor simply transfers values for the function's 
parameters to the WB_ASP, starts the function and waits for it to return. If the hardware 
function delivers a return value, this will be read back by the host processor, to be used in the 
calling software routine. 

1.  From the Libraries panel, select the FPGA Peripherals.IntLib file. 
2.  Locate the WB_ASP peripheral and select Place WB_ASP

12­94 
3.  Designate the component U6 and place the component so the ‘io_’ set of signal pins 
align with the newly created port on the Wishbone Interconnect component U1. 
4.  Wire the component as it appears in the following figure (you may need to increase the 
size of your schematic document to make room for your wiring). 

The ‘io_’ interface represents the interface to the processor.  The ‘me_’ interface 
represents the interface to memory.  Over the next few exercises we will complete the 
wiring, giving the ASP access to memory. 
5.  Update the processor peripheral memory to include the ASP by right­clicking the 
processor and selecting Configure Processor Peripheral... then selecting 
Import From Schematic to import the new configuration in the Configure 
Peripherals dialog. 

12.6  Exercise 26 – Giving the ASP Access to Memory (part 1) 
In this exercise we will add another Wishbone Interconnect on the memory side of our design 
configuring it such that we can access both memories our video capture, and video display 
memories. 

1.  From the Libraries panel, select the FPGA Peripherals.IntLib file. 
2.  Locate the WB_INTERCON peripheral and select Place WB_INTERCON. 
3.  Designate the component U15 
4.  Open the Component Properties dialog and select Configure 
5.  Select Add Device and add a new slave interface configured as it has been in the 
following figure:

12­95 
Figure 61.  Specifying the ASP interface to  XRAM1 

6.  Click OK to return to the Configure U15 (Wishbone Intercon) dialog. 
7.  Select Add Device and add a new slave interface configured as it has been in the 
following figure: 

Figure 62.  Specifying the ASP interface to XRAM2

12­96 
8.  Click OK to return to the Configure U15 (Wishbone Intercon) dialog. 
9.  Click OK to close the Configure U15 (Wishbone Intercon) dialog. 
10.  Wire the design as it appears Figure 63 
11.  Save your work. 

Figure 63.  Wiring the ASP to interconnect to both memories 

12.7  Exercise 27 – Giving the ASP Access to Memory (part 2) 
In this exercise we will give each of the two Wishbone Multi Master components an 
interface that allows the ASP access to the display and capture memories. 

1.  Right Click the Wishbone Multi Master component U3 and select Configure U3 
(WB_MULTIMASTER)… 
2.  We will need to add an additional master interface to component U3.  Configure U3 as it 
appears in the following dialog.

12­97 
Figure 64.  Updating the multimaster U3 

3.  Click OK to close the dialog. 
4.  Right Click the Wishbone Multi Master component U12 and select Configure U12 
(WB_MULTIMASTER)… 
5.  We will need to add an additional master interface to component U12.  Configure U12 
as it appears in the following dialog.

12­98 
Figure 65.  Updating the multimaster U12 

6.  Click OK to close the dialog. 
7.  Wire the two components as they appear in Figure 66 and Figure 67. 
8.  Save your work.

12­99 
Figure 66.  Updated wiring for wishbone multimaster U3 

Figure 67.  Updated wiring for wishbone multimaster U3

12­100 
12.8  Configuring the ASP 
To begin realizing the benefits of C to Hardware we must first configure our Wishbone ASP 
component.  To configure, right click the component in schematic and select Configure U6 
(WB_ASP).  This will launch the Configure U6 (WB_ASP Properties) dialog seen in Figure 
68. 

Figure 68.  Configuring the wishbone ASP 

The following table describes the various options available in the configuration dialog. 

Option  Description 
Processor  Use this field to specify the processor, by 
designator, that is connected to the WB_ASP 
and which can therefore call functions that have 
been generated in hardware.

12­101 
Option  Description 
Generate ASP  This option provides the ability to enable or 
disable generation of hardware­compiled 
functions. With this option enabled, the C­to­ 
Hardware Compiler will be invoked when you 
compile and synthesize your design project. All 
functions that have been enabled for 
implementation in hardware will be created as 
electronic circuits in the FPGA fabric. 
Use ASP from Software  This option enables you to control, on a global 
level, whether functions compiled into hardware 
will be called by software­based functions 
running within the processor. If this option is 
disabled, the embedded compiler will generate 
the functions in software and these will be used. 
Address Bus Width  Use this field to specify the width of the 
WB_ASP's host interface address bus 
(io_ADR_I). This bus is used by the processor to 
access and pass values to parameters in a 
hardware function, and also to access and read 
back a function's return value, where applicable. 
The width specified here should be large enough 
to include all parameters of the largest function 
being implemented in hardware. 
Extra Space  Use this field to specify the amount of blank 
space between the host processor and external 
memory interfaces to the device. 
Symbols in Hardware –  This list reflects all global variables present in the 
linked embedded software project. If you want to 
Global Variables  have a variable allocated in hardware, simply 
enable the corresponding check box in the 
Allocate in Hardware column. Such a variable 
will be allocated in ASP block RAM by the CHC 
Compiler. Access to this memory is much faster, 
in comparison to storage allocation in block RAM 
outside of the ASP by the Embedded Compiler. 
The list supports standard multi­select features, 
allowing you to quickly select multiple variables. 
Once selected, use the available right­click 
context menu commands to quickly enable 
(Push to Hardware) or disable (Remove from 
Hardware) the corresponding Allocate in 
Hardware option. 

Note that a global variable that is allocated in 
hardware can only be accessed by a function 
that has also been implemented in hardware. 
Such a variable cannot be called from a 
software­based function running on the host 
processor.

12­102 
Option  Description 
Symbols In Hardware –  This list reflects all functions present in the linked 
embedded software project. If you want to 
Function  implement a function in hardware ­ generated by 
the CHC Compiler as part of the ASP ­ simply 
enable the corresponding check box in the 
Implement in Hardware column. Should you wish 
to be able to call that hardware function from 
within the software running on the host 
processor, ensure that the corresponding check 
box in the Export to Software column is also 
enabled. 

The list supports standard multi­select features, 
allowing you to quickly select multiple functions. 
Once selected, use the available right­click 
context menu commands to:

· Push to Hardware ­ enable Implement in 
Hardware option for each function in the 
selection
· Remove from Hardware ­ disable 
Implement in Hardware option for each 
function in the selection
· Push and Export to Hardware ­ enable 
Implement in Hardware and Export to 
Software options for each function in the 
selection
· Unexport from Hardware ­ disable Export 
to Software option for each function in the 
selection. 

12.9  Exercise 28 – Accelerating our performance with ASP 
In this exercise we will configure the ASP to ‘offload’ some of the functionality of our design 
(previously done in software) into the FPGA hardware. 

1.  Right click the WB_ASP component U6 in the schematic and select Configure U6 
(WB_ASP)…  The following table describes the various options found in this dialog. 
2.  Configure the WB_ASP U6 to match the parameters in figure 69.

12­103 
Figure 69.  Configuring the wishbone ASP 

What we have done is move the two functions, rotate  and set_tabs  into hardware. 


The rotate  function performs the rotation of the video, and the set_tabs function 
builds our Sine and Cosine tables.  The global variables costab and sintab have 
also been moved to hardware as these are used by both of these functions and can be 
accessed more quickly when accessed from ASP block RAM. 
3.  Click OK to close the dialog. 
4.  Make sure your Desktop NanoBoard is connected to your PC and powered on. 
5.  Select View >> Devices View or click on the Devices View icon  in the toolbar. 
6.  Ensure that the Live checkbox is checked.  You should see a picture of the Desktop 
NanoBoard in the upper region of the display and an icon of the Spartan3 FPGA in the 
middle region. 
7.  In the drop down list just below the Spartan3 icon, ensure that the 
CHC_image_rotation / NBD2DSK01_07_DB30_04 project / configuration pair is 
selected.

12­104 
8.  Locate the Compile, Synthesize, Build, Program FPGA buttons running left to right 
just below the Desktop NanoBoard icon.  Click once on the words Program FPGA to 
begin the build process. 
9.  Once the design has completed the build process, return to the Devices view and right 
click the Digital IO instrument and select Instrument. 
10.  From the Instrument Rack, adjust the Rot[7..0] and Zoom[7..0] sliders to see the 
performance improvement when utilizing C to Hardware.

12­105 
13  OpenBus 
Until now, our discussions of FPGA design has really centered around schematic, with all 
devices in the system laid out on a schematic sheet or captured in a hardware description 
language such as VHDL or Verilog. Such designs suffer an inherent complexity, in terms of 
readability and as importantly, from a wiring / connectivity and configuration perspective. 

Using Altium Designer's OpenBus System we aim to greatly reduce such complexity. The 
fundamental purpose of this system is to represent the processor­peripheral interconnections 
in a much more abstract way. It achieves this by providing an environment in which to create 
your system that is highly intuitive, streamlined, and less prone to error. 

OpenBus System is created and managed using Altium Designer's OpenBus Editor. The 
OpenBus Editor has the familiar look and feel of Altium Designer's Schematic Editor, with its 
own unique set of resources for creation of an OpenBus System. Filtering and inspection are 
provided courtesy of the OpenBus Filter, OpenBus Inspector and OpenBus List panels, 
accessed from the OpenBus panel access button, to the bottom­right of the main design 
window. These resources provide a raised abstraction level for creating your processor­based 
design in a more visual and intuitive way. 

13.1  Creating an OpenBus version of our design 
Creating an OpenBus design begins like any other FPGA development effort in Altium 
Designer, with the creation of a new FPGA Project.  To that project, source documents are 
added and may include any combination or Schematics, VHDL or Verilog files, as well as 
OpenBus documents. 

Any FPGA design project that uses this system must have a top­level schematic as all 
interface circuitry remains on the top­sheet. The main processor system is defined in a 
separate, OpenBus System document (*.OpenBus) and connectivity between the two is made 
through a sheet symbol placed on the schematic. 

In this section we will create our equivalent design using OpenBus, though we will, for 
simplicity’s sake, eliminate the virtual instruments and instead simply focus on getting the 
image onto the TFT. 

13.2  Exercise 29 – Beginning an FPGA Project Using 
OpenBus 
1.  Select File»New»Project»FPGA Project to create a new, blank FPGA project 
2.  Right click the project FPGA project FPGA_Project1.PrjFpg in the Projects 
panel and select Add New to Project»OpenBus System Document 
3.  Right click the project FPGA project FPGA_Project1.PrjFpg in the Projects 
panel and select Add New to Project»Schematic 
4.  Right click the project FPGA project FPGA_Project1.PrjFpg  in the Projects 
panel and select Save Project As…  This will prompt you to first save the schematic, 
then the OpenBus document, and lastly the FPGA project document.  Save these as 
Video_Capture_Schematic.SchDoc, Video_Capture_OpenBus.OpenBus, and 
Video_Capture.PrjFpg respectively. 
5.  From the Projects panel, select the OpenBus document to give it focus in the main 
workspace.

13­106 
13.3  OpenBus Devices 
The starting point for any OpenBus 
System document is the placement of 
the required devices that will 
constitute the system. These 
OpenBus components, as they are 
called, are placed from the OpenBus 
Palette panel. Open this panel from 
the OpenBus button to the bottom­ 
right of the main design window. 

The panel contains graphical 
representations of devices available 
for FPGA design in Altium Designer, 
grouped by function:

· Connectors
· Processors
· Processor Wrappers
· Memories
· Peripherals 

Placement of OpenBus components is 
simply a case of clicking the required 
entry in the OpenBus Palette panel 
and then placing at the desired 
location in the workspace. Familiar 
schematic placement controls, such 
as flipping and rotating allow for fine 
tuning as needed. 

Figure 70.  The OpenBus palette. 

13.4  Exercise 30 – Placing Open Bus Components (part 1) 
Recall that in our original schematic we used only a handful of cores to create the basic 
functionality required by our design.  This included:
· BT656 Controller
· I 2 C Controller
· Wishbone Port IO
· Wishbone Display Driver
· TSK3000A
· 2 x SRAM Controllers 
We then also used:
· 2 x Configurable Wishbone Interconnect components
· 2 x Wishbone MultiMaster components 
…To manage the basic interconnectivity in our design.

13­107 
Lastly we used a handful of Virtual Instruments that completed the user interface to our 
design. 
In this exercise we will begin to place the basic components of our OpenBus system. 

1.  Ensure the OpenBus document VideoCapture.OpenBus is the currently focused 
document in the workspace. 
2.  Locate the OpenBus panel either using the OpenBus button on the lower right of the 
workspace or by selecting View»Workspace Panels»OpenBus»OpenBus Palette. 
3.  Locate the TSK3000A in the Processors section of the OpenBus Palette and single­ 
click it to switch to placement mode. 
4.  Move the cursor over the center of the OpenBus document and click once to place the 
component into the document. 
5.  Single­click the component text TSK3000A_1 and hit F2 to perform an In­Place edit of 
the text.  Change this to MCU as seen in the Figure 71. 
Figure 71.  Naming the TSK3000 

TSK3000A_1  MCU 

IO  MEM  IO  MEM 

6.  The two red dots on the outside of the component body represent 
the two master interfaces to the host processor.  These can be 
moved with respect to the component body by simply clicking and 
dragging. 

Reposition the IO and Memory Interfaces as they appear in the following figure.  These 
will automatically snap into position as required. 

MCU  MCU
MEM 
IO 

IO  MEM 

Figure 72.  Repositioning the OpenBus ports on the MCU 

13­108 
7.  Return to the OpenBus panel and locate the Video Capture Controller component in 
the Peripherals section.  Select this component and place it into the OpenBus 
document. 
8.  Single­click the component text BT656_1 and hit F2 to perform an In­Place edit of the 
text.  Change this to VIDEO as seen in Figure 73. 

BT656_1  VIDEO 

Figure 73.  Renaming the video capture controller 

9.  The Red OpenBus port  represents a Wishbone Master interface.  This interface is 


used to connect the Video Capture controller to memory. 

The Green OpenBus port  represents a Wishbone Slave interface.  This interface 
is used to connect the device to the host processor, via the Wishbone Interconnect 
component. 

Reposition the Green and Red OpenBus ports as seen in the following figure. 

BT656_1  VIDEO

Figure 74.  Repositioning OpenBus ports on the capture controller 
10.  Return to the OpenBus panel and locate the ASP component in the Peripherals 
section.  Select this component and place it into the OpenBus document. 
11.  Single­click the component text WB_ASP and hit F2 to perform an In­Place edit of the 
text.  Change this to ASP. 
12.  Reposition the Green and Red OpenBus ports consistent with the Video Capture 
Controller. 
13.  Return to the OpenBus panel and locate the VGA 32­Bit TFT Controller component in 
the Peripherals section.  Select this component and place it into the OpenBus 
document. 
14.  Single­click the component text VGA32_TFT_1 and hit F2 to perform an In­Place edit of 
the text.  Change this to TFT. 

15. 

13­109 
16.  Reposition the Green and Red OpenBus ports consistent with the Video Capture 
Controller. 
17.  Return to the OpenBus panel and locate the I 2 C component in the Peripherals section. 
Select this component and place it into the OpenBus document. 
18.  Single­click the component text I2CM_W_1 and hit F2 to perform an In­Place edit of the 
text.  Change this to I2C. 
19.  Position the Green OpenBus port to the right of the component as it appears in the 
following figure: 

I2CM_W_1 I2C 

Figure 75.  Renaming the I2C controller 

20.  Return to the OpenBus panel and locate the Port IO component in the Peripherals 
section.  Select this component and place it into the OpenBus document. 
21.  Single­click the component text WB_PRTIO_2 and hit F2 to perform an In­Place edit of 
the text.  Change this to GPIO. 
22.  Finally, reposition the OpenBus components in the schematic as they appear in the 
following Figure. 

13­110 
GPIO  VIDEO 

MCU 

MEM 
IO 
ASP 

I2C  TFT 

Figure 76.  Positioning the processor and peripherals 

The alignment tools used in a traditional Altium Designer schematic are also available 
under OpenBus.  These are all accessible under the single key shortcut ‘A’.  These 
tools make the process of placing and aligning the OpenBus components faster and 
easier. 

13.5  Exercise 31 – Using an Interconnect 
As in schematic, OpenBus designs utilize Interconnect components to interconnect any 
number of slave devices to a single master.  In this exercise we will place our Interconnect 
component and connect our peripheral devices to the host processor.  You will find this 
process to be greatly simplified under the OpenBus paradigm. 

1.  From the Connectors section of the OpenBus Palette, select the Interconnect 
component and place the component such that the green Slave interface aligns directly 
to the left of the host processor’s red Master interface labeled IO. 
2.  Single­click the component text WB_INTERCON_1 and hit F2 to perform an In­Place 
edit of the text.  Change this to I_IO. 
3.  Locate the OpenBus toolbar along the top of the 
main workspace.  The following table describes 
each of the items in this toolbar.

13­111 
Toolbar Item  Command  Description 

Link OpenBus Ports  Use this command to link the ports of devices 
within your OpenBus System. When you enter 
link addition mode, all currently unlinked ports 
will be filtered, with all other elements in the 
system dimmed. 
If you click to start a link on a master port, all 
currently unlinked slave ports will be filtered 
and available for choosing the termination 
point of the link. Conversely, if you click to start 
a link from a slave port, all currently unlinked 
master ports will be filtered and made 
available. 
To remove a link, simply click to select it in the 
workspace, then press the Delete key. 

Add OpenBus Ports  Use this command to add one or more 
additional ports to an Interconnect or Arbiter 
component in the OpenBus System document. 
After launching the command, a dimmed port 
shape will appear floating on the cursor. As 
you move the shape next to the perimeter of a 
component, it will become solid ­ darker gray 
with a blue outline. Position the new port as 
required and click to effect placement. 
When adding the port to an Interconnect 
component, a new master port will be added. 
When adding the port to an Arbiter component, 
a new slave port will be added. 
Continue adding further ports as required, or 
right­click or press Esc to exit port addition 
mode. 

Normalize OpenBus  This command allows you to quickly normalize 
Link(s) Shape  the shape of one or more links in the OpenBus 
System document. Ensure that all links to be 
normalized are selected prior to launching the 
command. Once the command is launched, all 
links in the selection will revert back to the 
standard shapes they had when first placed.

13­112 
Toolbar Item  Command  Description 

Flip OpenBus Link(s)  This command allows you to quickly flip one or 
Shape  more links in the OpenBus System document. 
Ensure that all links to be flipped are selected 
prior to launching the command. 

Straighten OpenBus  Allows you to quickly straighten one or more 
Link(s) Shape  links in the OpenBus System document. 
Ensure that all links to be straightened are 
selected prior to launching the command. 
Once the command is launched, all links in the 
selection will be straightened, going from 
source master port to destination slave port. 

Manage OpenBus  Use this command to access the OpenBus 
Signals and Interrupts  Signal Manager dialog. This dialog is used to 
manage the clock, reset and interrupt lines for 
the system. 
The export of interrupt lines outside of the 
OpenBus System document is handled using this 
dialog. 
The dialog provides an External connection 
summary tab. This lists each of the peripheral 
or memory devices used in the system, and 
the external interface signals associated with 
them. These signals are the ports that 
correspond to the sheet entries of the sheet 
symbol on the top­level schematic sheet ­ the 
method by which the OpenBus System is 
hooked into the overall FPGA design. 

4.  For our design we will need to add additional Master ports to our Interconnect 
component.  These will enable us to connect the additional peripherals to our host 
processor. 
Press the Add OpenBus Port button  in the OpenBus toolbar and click once over 
the red Master port on the Interconnect component.  Notice how the ports are 
automatically aligned. 
5.  Place 3 additional OpenBus ports to bring the total to 1 Slave Port (the interface to the 
host processor) and 5 Master Ports (the interfaces to our various peripherals). 
6.  Simply clicking and dragging on any port will allow you to reposition it around the 
outside of the body of the Interconnect device.  Align the ports to match the following 
figure. 
I_IO  MCU 
MEM 
IO 

Figure 77.  Positioning the ports on the interconnect component 
7.  Save your work

13­113 
13.6  Exercise 32 – Linking OpenBus Ports 
In this exercise we will be linking the OpenBus ports to one another on the peripheral half of 
our design.  This can best be likened to wiring the Wishbone Interfaces of schematic 
components to one another in the schematic editor; however this process has been even 
further simplified under OpenBus. 
1.  From the OpenBus toolbar, select the Link OpenBus Ports command  and the cursor 
will change to a cross­hair. 
2.  Click on one of the Master ports on the Interconnect component I_IO.  Notice how only 
the valid Slave interfaces are available for selection.  Clicking on a Slave interface will 
connect the two devices to one another and the signals required to connect these two 
components will be managed automatically by the software. 
This is a key component of the OpenBus system and something not to be taken lightly. 
And though what is ‘under the hood’ is always available for us to inspect, there’s little 
need when using the cores supplied with Altium Designer. 
3.  Connect each of the peripherals to the interconnect component as displayed in the 
figure below.  Experiment using the OpenBus toolbar options to Normalize  , Flip  , 
and Straighten  the OpenBus connections. 

GPIO  VIDEO 

I_IO  MCU 

MEM 
IO 

ASP 

I2C  TFT 

Figure 78.  Connecting the peripherals

13­114 
13.7  Exercise 33 – Configuring our processor under open bus 
The process of configuring the host processor under OpenBus is in many ways identical to 
the way in which a processor is configured in schematic.  In this exercise we will configure the 
host processor for use in our design. 
1.  Right click the host processor in the OpenBus document and select Configure MCU 
(TSK3000A)… 
2.  Configure the processor options found in the Configure (32­bit Processors) dialog as 
they appear in Figure 79. 

Figure 79.  Configuring the processor 

3.  Click OK to close the dialog. 
4.  Save your work. 

13.8  Exercise 34 – Configuring the GPIO Component 
In this exercise we will configure our GPIO component to include the ports required to 
connect our LEDs and Virtual Instruments to this design. 
1.  Right click the GPIO component and select Configure GPIO (Port IO)… 
2.  Configure the settings in the Configure OpenBus Port I/O as they appear in Figure 80. 

Figure 80.  Configuring the Port IO

13­115 
Each of the ports specified in the dialog will be converted to a sheet entry later in this 
design.  When specifying Input/Output as the Kind, two separate sheet entries will be 
created, one for the input, another for the output. 

3.  Click OK to close the dialog. 
4.  Save your work. 

13.9  Exercise 35 – Finalizing the Interconnect Component 
In this exercise we will configure the Interconnect component, defining the characteristics of 
each of the peripherals as they exist in the processor’s memory space.  This process has 
been streamlined under OpenBus as many of these attributes can be inferred from the 
peripherals. 

For example, we can infer from our Port IO that were we to select 4 ports in the GPIO 
configuration dialog, we would require 2 bits to address each of the 4 ports.  Under OpenBus, 
these values are populated automatically and only require us to specify the number of bits to 
decode and the base address of each of the peripherals. 

1.  Right click the I_IO component and select Configure I_IO (Interconnect)… 
2.  Clicking on a field and hitting F2 will allow you to make edits to the contents of each 
field.  Configure the settings in the Configure OpenBus Interconnect dialog to match 
the figure below. 

Figure 81.  Configuring the OpenBus Interconnect 

3.  Click OK to close the dialog. 
4.  Save your work.

13­116 
13.10  Defining the Memory Side of our System 
As we’ve seen in the schematic portion of the course, this design requires external memory. 
In this section we will add the IP necessary to access memory resources on the Desktop 
NanoBoard. 

13.11  Exercise 36 – Adding the Remaining Components 
In this exercise we will add the final few parts for the OpenBus portion of our design.  Below 
is a list of these parts, all of which should seem familiar given the earlier schematic­based 
approach we’ve already completed.

· 2 x Interconnect components (named I_MCU, I_ASP)
· 2 x Arbiter components (named MULTIMASTER_1, MULTIMASTER_2)
· 2 x SRAM Controller (named XRAM1, XRAM2) 

From the OpenBus Palette, place the above named components as they appear in the 
following figure.  Note the additional Master and Slave ports on the Interconnect and Arbiter 
components respectively. 


MULTIMASTER_1 
XRAM1 


I_MCU 

XRAM2 


I_ASP 

MULTIMASTER_2 

Figure 82.  Placing the memory and memory interconnects / arbiters

13­117 
13.12  Exercise 37 – Completing the Connectivity 
In this exercise we will complete the connectivity required by the memory portion of our 
design.  Using the toolbar command Link OpenBus Ports, connect the ports as they appear 
in the following figure. 

VIDEO 


MULTIMASTER_1  XRAM1 


MCU  I_MCU 
MEM 
IO 

ASP 

XRAM2 


TFT  I_ASP 

MULTIMASTER_2 

Figure 83. Connecting the memory side of the design 

13.13  Exercise 38 – Configuring the SRAM Controllers 
In this exercise we will configure the two SRAM Controllers for use by our design.  If you 
recall from the schematic portion of the course, both of these controllers interfaced to 
SRAM on the Desktop NanoBoard.  The sizes of these memories had been constrained by 
the devices on the board, and the requirements of the design. 

1.  Right click XRAM1 in the OpenBus document and select Configure XRAM1 (SRAM 
Controller) to launch the component’s configuration dialog. 
2.  This dialog matches exactly the dialog we had used in schematic.  In the Configure 
(Memory Controller) dialog, specify the settings to match the following figure.

13­118 
Figure 84.  Configuring the Memory Controller XRAM1 

3.  Click OK to close the dialog and return to the OpenBus document. 
4.  Right click XRAM2 in the OpenBus document and select Configure XRAM2 (SRAM 
Controller) to launch the component’s configuration dialog. 
5.  In the Configure (Memory Controller) dialog, specify the settings to match the 
following figure. 

Figure 85.  Configuring the Memory Controller XRAM2 

6.  Click OK to close the dialog and return to the OpenBus document. 
7.  Save your work.

13­119 
13.14  Exercise 39 – Configuring the Arbiters 
In this exercise we will configure the two Arbiter components for use by our design.  If you 
recall from the schematic portion of the course, there was one arbiter for each of the two 
memories.  These manage the processor, ASP, and capture and display cores access to 
memory. 
Under the OpenBus system, the interface to the arbiters has been simplified considerably. 
Because of the addition of the OpenBus ports, we are no longer required to add additional 
items to the arbiter and manage naming and pin spacing.  Instead, we are only required to 
select the way masters contest for the slave resource and specify the master with no delay. 

1.  Right click MULTIMASTER_1 in the OpenBus document and select Configure 
MULTIMASTER_1 (Arbiter) to launch the component’s configuration dialog. 
2.  In the Configure OpenBus Arbiter dialog, specify the settings to match the following 
figure. 

Figure 86.  Configuring the OpenBus arbiter 

3.  Click OK to close the dialog and return to the OpenBus document. 
4.  Right click MULTIMASTER_2 in the OpenBus document and select Configure 
MULTIMASTER_2 (Arbiter) to launch the component’s configuration dialog. 
5.  In the Configure OpenBus Arbiter dialog, specify the settings to match the following 
figure. 

Figure 87.  Configuring the OpenBus arbiter

13­120 
13.15  Exercise 40 – Configuring the Interconnects 
In this exercise we will configure the two Interconnect components for use by our design. 
If you recall from the schematic portion of the course, there were two interconnects, one for 
the memory and another for the ASP.  These allowed us to split the interfaces of these two 
components across two different memories such that they each had access to both of the 
memories. 

1.  Configure both of the OpenBus Interconnect components I_MCU and I_ASP as it 
appears in the following dialog. 

Figure 88 ­ Configuring the OpenBus Interconnect 

2.  Click OK to return to the OpenBus document. 
3.  Save your work. 

13.16  Finalizing the OpenBus Portion of the Design 
At this stage, we have nearly completed the OpenBus portion of our design and it should be 
obvious that by using OpenBus, the process of capturing your design becomes faster. 
Likewise it’s important to recognize how much more accurate the connectivity can be when 
it’s relegated to the software to sort out and not a human process. 
As we complete the OpenBus portion of our design, one thing remains, and that is the 
configuration of the processor memory.  If you recall from our schematic discussions, the 
processor memory was being auto­defined by a hardware.h file.  We had selected this option 
rather than rely on the error­prone process of having to manually key in this data every time 
we made a change to our design. 
Under OpenBus, this process is nearly identical and the next exercise will revisit this.

13­121 
13.17  Exercise 41 – Configuring the Processor Memory 
In this exercise we will configure the processor’s peripheral and internal memories.  We will 
also configure the processor to use the auto­generated hardware.h file, rather than try 
maintaining the memory configuration manually. 

1.  Right click the component MCU in the OpenBus document and select Configure 
Processor Memory to launch the Configure Processor Memory dialog. 
2.  Ensure that the hardware.H (C Header File) checkbox is checked and ensure that the 
memory configuration above appears as it does in Figure 89. 

Figure 89. Configuring the processor memory 

3.  Select the Configure Peripherals button to launch the Configure Peripherals dialog. 
4.  Ensure that the hardware.H (C Header File) checkbox is checked and ensure that the 
memory configuration above appears as it does in Figure 90.

13­122 
Figure 90.  Configuring the processor peripheral memory 

5.  Click OK to return to the OpenBus document. 
6.  Save your work. 

13.18  Exercise 42 ­ Creating a sheet symbol from an 
OpenBus Document 
To link the OpenBus document to a parent schematic, you need to create a sheet symbol 
from the OpenBus document and place it on the parent schematic.  In this exercise we will 
create sheet symbol from the open bus document. 
1.  Open Video_Capture_Schematic.SchDoc 
2.  Select Design >> Create Sheet Symbol From Sheet or HDL. 
3.  When the Choose Document to Place dialog box appears, select the 
Video_Capture_OpenBus.OpenBus document and click OK. 
4.  A large sheet symbol will be attached to the cursor. Position it at the center of the 
schematic page and click once to commit the placement. 
The sheet entries on the newly placed sheet symbol have been loosely grouped with 
inputs on the left and outputs on the right. You must now go through a process of 
unraveling all of these sheet entries so that you can connect them to the port plugins on 
the NanoBoard more easily.

13­123 
5.  A sheet symbol with the various sheet entries properly organized is located in the 
Snippets panel as OpenBus_Sheet_Symbol.  If you intend to use this symbol be 
certain your filename matches the filename in the Sheet Symbol properties. 
6.  A snippet has also been created with the basic Port Plug In components, placed and 
ready to be wired into your sheet symbol.  You can find this in the Snippets panel under 
listed as Open_Bus_PortPlugIns. 

13.19  Exercise 43 – Linking an Embedded Project to an 
OpenBus Design 
The Process of Linking an OpenBus FPGA Design to an Embedded Project is identical to the 
process with which we linked these two projects we’d created the design using a schematic­ 
only flow. 

1.  From the Projects panel, switch to the Structure Editor mode. 
2.  Locate the embedded project EmbeddedProject.PrjEmb in the Valid Sub Projects and 
Configurations section at the bottom of the dialog. 
3.  Drag and drop the embedded project over MCU (TSK3000A) in the top section of the 
panel.  This will link the two projects. 
Note:  Embedded projects can be linked to more than one FPGA project.  This makes 
the process of porting code from one design to another quite easy. 

Figure 91 – Linking the two projects 

4.  Return to the File View mode in the Projects panel. 
5.  Save your work.

13­124 
13.20  Exercise 44 – Processing an OpenBus Design 
The Process of Constraining and Building an OpenBus FPGA Design is identical to the 
process we’d undergone when we’d built our design using a schematic­only flow.  In this 
exercise we will revisit the process of constraining and building our design. 

1.  First we need to configure our design.  With the FPGA and Embedded Projects linked, 
switch to the Devices View under View»Devices Views or by hitting the  button in 
the toolbar at the top of the screen. 
2.  Right Click the image of the Desktop NanoBoard at the top of the window in the 
Devices View and select Configure FPGA Project»Video_Capture.PrjFpg 

Figure 92 – Auto configure the OpenBus design 

This will automatically configure the FPGA Project to include the constraint files 
required to target the hardware on the Desktop NanoBoard and will launch the 
Configuration Manager For Video_Capture.PrjFpg dialog. 
3.  Within the Configuration Manager, click the Add button to add a constraint file to the 
existing configuration. 
4.  Locate the MyConstraint.constraint file and add this to the current configuration (this file 
had been used by our previous schematic­only implementation of this project). 
5.  Locate MyConstraints.Constraint in the Constraint Files columns and check the box in 
the Configurations column to add it to the existing configuration. 
6.  Click OK to close this dialog and the Hard JTAG Chain should appear now in the main 
window.  Likewise, the Soft, Nexus JTAG Chain should display the Host Processor 
MCU and our Virtual Instruments. 
7.  Save your work. 
8.  Locate the Compile, Synthesize, Build, Program FPGA buttons running left to right 
just below the Desktop NanoBoard icon.  Click once on the words Program FPGA to 
begin the build process.

13­125 
14  Review

14­126 
FPGA to PCB 
Training Module
Document Version 1.2, February 2008 

Software, documentation and related materials: 
Copyright © 2008 Altium Limited. 
All rights reserved. You are permitted to print this document provided that (1) the use of such is for 
personal use only and will not be copied or posted on any network computer or broadcast in any 
media, and (2) no modification of the document is made. Unauthorized duplication, in whole or part, 
of this document by any means, mechanical or electronic, including translation into another 
language, except for brief excerpts in published reviews, is prohibited without the express written 
permission of Altium Limited. Unauthorized duplication of this work may also be prohibited by local 
statute. Violators may be subject to both criminal and civil penalties, including fines and/or 
imprisonment. 
Altium, Altium Designer, Board Insight, CAMtastic, CircuitStudio, Design Explorer, DXP, LiveDesign, 
NanoBoard, NanoTalk, Nexar, nVisage, P­CAD, Protel, SimCode, Situs, TASKING, and Topological 
Autorouting and their respective logos are trademarks or registered trademarks of Altium Limited or 
its subsidiaries. 
Microsoft, Microsoft Windows and Microsoft Access are registered trademarks of Microsoft 
Corporation. OrCAD, OrCAD Capture, OrCAD Layout and SPECCTRA are registered trademarks of 
Cadence Design Systems Inc. AutoCAD is a registered trademark of AutoDesk Inc. HP­GL is a 
registered trademark of Hewlett Packard Corporation. PostScript is a registered trademark of Adobe 
Systems, Inc. All other registered or unregistered trademarks referenced herein are the property of 
their respective owners and no trademark rights to the same are claimed. 

Module 3
Altium Designer Training  FPGA to PCB 

FPGA to PCB Training Module 
1.  From FPGA project to PCB project...................................................................... 3­2 
1.1  Understanding the document stack............................................................. 3­2 
1.2  Using the FPGA to PCB project wizard ....................................................... 3­4 
1.3  Choosing the FPGA configuration............................................................... 3­4 
1.4  Initial FPGA pin assignments...................................................................... 3­5 
1.5  Choosing the target PCB project................................................................. 3­7 
1.6  Configuring the FPGA component schematic sheet .................................... 3­7 
1.7  Configuring the sheet symbol schematic sheet ........................................... 3­8 
1.8  Exercise 1 – Running the FPGA to PCB project wizard............................... 3­9 
1.9  Modifying the auto generated sheet .......................................................... 3­11 
1.10  A word about special function FPGA pins ................................................. 3­11 
1.11  Recreating the autogenerated sheet ......................................................... 3­12 
2.  Maintaining project synchronization ................................................................. 3­13 
2.1  The FPGA workspace map....................................................................... 3­13 
2.2  The synchronize dialog............................................................................. 3­14 
2.3  Synchronizing matched signals................................................................. 3­16 
2.4  Synchronizing unmatched signals............................................................. 3­17 
3.  Configuring FPGA I/O ......................................................................................... 3­20 
3.1  Configuring I/O standards......................................................................... 3­20 
3.2  Exercise 2 – Using the FPGA signal manager........................................... 3­21 
4.  Manually linking FPGA and PCB projects ......................................................... 3­23 
4.1  Supported devices.................................................................................... 3­24 
4.2  Creating the link ....................................................................................... 3­24 
4.3  Linking an auto generated sheet to an existing PCB project ...................... 3­27 
4.4  Exercise 3 – Manually linking a PCB and FPGA project ............................ 3­27 
5.  Pin swapping ...................................................................................................... 3­28 
5.1  Pin swapping in the PCB document .......................................................... 3­28 
5.2  Pin swapping in the FPGA project............................................................. 3­35 
5.3  Pin swapping in both PCB and FPGA projects .......................................... 3­36 
5.4  Exercise 4 – Pin swapping........................................................................ 3­36 
6.  Commissioning the design ................................................................................ 3­38 
6.1  Exercise 5 – Migration stage 1.................................................................. 3­38 
6.2  Exercise 6 – Migration stage 2.................................................................. 3­39 
6.3  Exercise 7 – Calibration............................................................................ 3­39 
6.4  Exercise 8 – Bootstrapping the FPGA....................................................... 3­40 
6.5  Exercise 9 – Reverting to test mode ......................................................... 3­41 
7.  Review................................................................................................................. 3­42


Altium Designer Training Module  FPGA to PCB 

1. From FPGA project to PCB project 
At some point in the life of all designs there comes a point where they must move from the laboratory 
prototype to production.  If a design has been successfully running on the Desktop NanoBoard, the 
process of migrating from an FPGA based project to a PCB based project containing the FPGA 
project is simplified through the use of the FPGA to PCB Project Wizard.  This method 
automatically links the two projects and maximizes synchronization functionality between them. 
Project synchronization is important as it ensures that design changes made to either the PCB 
document or FPGA project are propagated in a controlled fashion. 
Over the remainder of the course we will look at moving a design from the test environment, to the 
target PCB.  To do this we will use a design that has already been completed for us, a Digital Spirit 
Level.  The FPGA portion of this design includes a softcore TSK51 processor which takes as its input 
the output of an accelerometer and outputs a small bubble on an LCD mimicking a traditional spirit 
level. 

1.1  Understanding the document stack 

Figure 1. Visualization of how the various project documents are stacked 

Synchronization between PCB and FPGA projects is carried out and maintained by establishing a 
link between the top­level ports in the FPGA project – specified in the relevant constraint file – and 
the corresponding pins on the FPGA component schematic. Linking is achieved using the signal 
name. The name given to the port in the FPGA project must be the same as the net label assigned 
to the corresponding pin on the schematic component in the PCB project.  Figure 1 provides a 
visualization of how the various documents in an FPGA/PCB project stack are linked together.

3 ­ 2 
Altium Designer Training Module  FPGA to PCB 

FPGA_Top.SchDoc  FPGA project 
The top level FPGA schematic document 
must contain ports at the point where 
signals are connected to physical pins on 
the FPGA device.  The name of the ports is 
important as they will be used in the 
constraints file. 

FPGA.Constraint  FPGA project 
The Constraint file defines the physical pin 
number that ports defined in the top level 
FPGA schematic will be connected to.  This 
is referred to as a port name to FPGA pin 
number mapping.  Port names declared in 
the constraint file must match those 
included in the top level FPGA schematic 
document. 

FPGA_Auto.SchDoc  PCB project 
The autogenerated schematic sheet is 
created from information contained in the 
FPGA constraint file.  Essentially the 
autosheet is a schematic representation of 
the port to pin mappings made by the 
constraint file.  Port to pin connectivity on 
the autosheet is accomplished through the 
use of net labels – i.e. a net label is 
attached to wires connected to the ports on 
the sheet and a corresponding net label is 
also attached to the device pin. 

FPGA_Manual.SchDoc  PCB project 
An optional ‘manual’ sheet is generated as 
part of the FPGA to PCB project wizard. 
This manual sheet contains a sheet symbol 
of the autosheet – the ports on the 
autosheet are connected to corresponding 
ports on the sheet symbol.  Connecting to 
this sheet symbol rather than directly to the 
FPGA symbol introduces an important 
abstraction layer.  This layer facilitates easy 
(automated) updates to the project if the 
device or pin allocations should change as 
the project develops. 
TargetPCB.PCBDoc  PCB project 
The FPGA depicted in the autosheet and 
abstracted on the ‘manual’ sheet will 
eventuate into a physical device on the final 
PCB.  The physical pins of this device will 
be connected to ports as described in the 
autosheet. 
Figure 2. The role of the various documents in the project stack

3 ­ 3 
Altium Designer Training Module  FPGA to PCB 

1.2  Using the FPGA to PCB project wizard 
With a schematic document in the FPGA project open as the active view in the main design window, 
simply choose the Tools » FPGA To PCB Project Wizard entry from the menu. The wizard will 
appear, as shown in Figure : 

Figure 3. The FPGA To PCB project wizard. 

1.3  Choosing the FPGA configuration 
The second page of the wizard allows you to choose the configuration that will be used for targeting 
the FPGA design to the PCB. The configuration uses a constraint file that defines the FPGA device 
to be used and its associated pin mappings. 
The configuration can either be an existing one that you have already defined as part of the FPGA 
project, or a new one, generated by the wizard. In the case of the latter, the wizard will generate a 
configuration and add to it a new constraint file. These will have default names (PCB 
Configuration and PCB Constraints.Constraint respectively) and the constraint file will be 
stored in the same location as the FPGA project file (*.PrjFPG), unless otherwise specified. 

Figure 4. Wizard­based configuration generation. 

The constraint file that is added to the configuration will contain a target device definition for the 
FPGA project, according to the device you select in the Selected Device field. You can browse for a 
device by clicking the … button, to the right of the field. This will open the Choose Physical Device 
dialog, from where you can peruse from a number of devices available across a spectrum of FPGA 
vendor­device families.

3 ­ 4 
Altium Designer Training Module  FPGA to PCB 

Figure 5. Browsing for the required FPGA device. 

1.4  Initial FPGA pin assignments 
The second page of the FPGA to PCB Project wizard gives you the choice of what to do with 
unconstrained ports – i.e. ports that have not been tied to a specific pin on the target device.  The 
decision as to how these pins are assigned is somewhat arbitrary and so there are a number of ways 
of doing this: 

1.4.1  Importing pin file from vendor place and route tools 
Clearly for this option to be available the design must have previously been built for the current 
device and a constraint file and configuration must already exist.  For totally new designs this is the 
preferred design path.  It ensures that the vendor tools are given the most opportunity to optimize the 
design without being unduly constrained and it ensures that the selected device is capable of 
supporting the design.  In this case, the pin assignments should be made prior to running the FPGA 
to PCB project wizard.  With a constraint file open in the main window, select Design » Import Pin 
File from the menu to import the vendor pin file.  The following dialog box will appear: 

Figure 6. Selecting constraints to be imported from the vendor tools

3 ­ 5 
Altium Designer Training Module  FPGA to PCB 

1.4.2  Assigning pins during the FPGA to PCB wizard 
Probably the quickest and simplest way to allocate pins is whilst executing the FPGA to PCB project 
wizard.  Select the Assign Unconstrained Ports on the second page of the wizard.  As the wizard 
executes it will automatically allocate pin numbers to unallocated ports updating the constraint file 
and auto generated sheet as it goes. 

Figure 7. Assigning unconstrained ports as part of the FPGA to PCB project wizard 

1.4.3  Assigning unconstrained signals from the FPGA signal manager 
It is also possible to allocate unconstrained signals by selecting the Assign Unconstrained Signals 
button in the FPGA Signal Manager dialog (Figure 8). 

Figure 8. Using the FPGA signal manager to assign unconstrained signals

3 ­ 6 
Altium Designer Training Module  FPGA to PCB 

Performing pin assignments via this method is probably less advisable as it does not give the user 
the choice which constraint file (project or target) records the pin allocations.  Furthermore, an 
additional step is required after this one to resynchronize the net labels in the auto­generated sheet. 

1.4.4  Assigning signals manually in the auto generated sheet 
This is the most laborious method and generally not advisable.  Using this method requires the 
designer to manually enter the net names for all ports onto the auto­generated sheet.  A second 
synchronization step is also required to propagate the pin assignments into the constraints file. 

1.5  Choosing the target PCB project 
After choosing the FPGA configuration, the actual target PCB project must now be defined. Simply 
accept the Wizard's generation of a new project (PCB Project1.PrjPCB), or browse to and select 
an existing project. In the case of a new PCB project, the file will be stored in the same location as 
the FPGA project. 

1.6  Configuring the FPGA component schematic sheet 
Whether the PCB project already exists or is being newly created, the relationship between the 
FPGA project and its corresponding component in the PCB project has to be managed in some way. 
This is achieved using a dedicated, auto­generated schematic sheet, referred to as the 'Main Sheet' 
in the Wizard. 

Figure 2. The auto­generated FPGA component schematic sheet. 

This schematic sheet will be created with the component symbol placed for the FPGA device 
targeted in the constraint file. The Wizard allows you to determine where and by what name, the 
schematic is created.  By default, the schematic will be named using the chosen designator for the 
FPGA component (e.g. FPGA_U1_Auto.SchDoc) and will be stored in the same location as the 
FPGA project.  Each used pin on the component symbol is linked to a port entry in the constraint file 
by signal (net label/port) name. The names for nets in the PCB project are therefore required to be 
the same as those in the FPGA project. Once linked, any changes made to the source documents of 
either PCB or FPGA project can be passed on, ensuring that the two projects remain synchronized.

3 ­ 7 
Altium Designer Training Module  FPGA to PCB 

1.6.1  Configuring unallocated I/O 
The Wizard also allows you to determine how any unused I/O pins on the component are handled. 
You have the ability to control the treatment of various categories of pin types individually – Input­ 
only pins, VREF pins, Special Function pins and all other unused pins. 
For each category, the pins can be handled in one of the following ways: 

Tie to single port  Tie all unused pins in the category to a single port (which will also 
appear on the parent sheet symbol (if applicable) on the sheet above) 
Tie to individual ports  Tie all unused pins in the category to their own, individual ports 
(which will also appear on the parent sheet symbol (if applicable) on 
the sheet above) 
Tie to ports by IO  Tie all unused VREF pins to a port on a bank by bank basis (which 
bank (VREF only)  will also appear on the parent sheet symbol (if applicable) on the 
sheet above). 
Add No ERC directive  Add a No ERC directive to an unused pin, so that it is not included as 
part of error checking when the design is compiled 
Ignore  Do nothing with an unused pin 
Figure 3. Selecting how unused I/O is to be handled 

Note: For VREF pins, when the Tie to single port or Tie to ports by IO bank options are selected, 
you are given the additional option of whether or not to connect via Power Ports. 
­­ 

1.7  Configuring the sheet symbol schematic sheet 
As part of the PCB project, you have the option of defining the 'owner' of the FPGA Component 
sheet (holding the component symbol for the FPGA device). The final page of the Wizard allows you 
to define the owner as a sheet symbol, which, if enabled, will be created on an additional schematic 
sheet, the name and location of which you can freely choose. By default, the schematic will be 
named using the chosen designator for the FPGA component on the previous page of the Wizard 
(e.g. FPGA_U1_Manual.SchDoc) and will be stored in the same location as the FPGA project. 
In summary, after all of the options in the Wizard have been set as required, the following will be 
generated:
· A new PCB project (if specified)
· A new schematic sheet, added to the new or existing PCB project, which contains the schematic 
representation of the FPGA component
· A new schematic sheet with parent sheet symbol (if specified). If an existing sheet is targeted, 
the parent sheet symbol for the FPGA Component schematic will be added/updated as 
necessary
· A new configuration (if specified), which will be added to the FPGA project file and which 
contains a new constraint file
· The constraint file – either new for a new configuration or an existing one contained in a chosen 
configuration – containing: 
­  a part constraint 
­  a PCB board constraint 
­  a list of constraints for all ports on the top­level source file of the FPGA project. Each of 
these port constraints is matched (and therefore linked), by net name, to the equivalent pin 
on the FPGA component in the PCB project's auto­generated schematic sheet.

3 ­ 8 
Altium Designer Training Module  FPGA to PCB 

1.8  Exercise 1 – Running the FPGA to PCB project wizard 
In this exercise we will utilize the design targeted to the Spartan2E device and we will run through 
the FPGA to PCB Project Wizard. 
1.  Open the design SpiritLevel.PRJFPG in the folder \Module3\Exercise 1\ 
2.  Open the configuration manager and make sure the NB1_6_XC2S300E­6PQ208.Constraint is 
included in the configuration. Click OK to close the configuration manager. 
3.  Open the FPGA schematic document – SL_FPGA_Complete.SchDoc. 
4.  Select Tools » FPGA to PCB Project Wizard. 
5.  At the Select the FPGA Configuration step, check the Use Existing Configuration option and 
specify NB_Xilinx_Spartan2 configuration.  Make sure Assign Unconstrained Ports is not 
checked. 

Figure 4. Use an existing configuration in the FPGA to PCB Project Wizard 

6.  At the Configure the PCB Project step, specify the PCB Project File Name as 
SpiritLevel_2E.PrjPCB. 

Figure 5. Specify the PCB project file name.

3 ­ 9 
Altium Designer Training Module  FPGA to PCB 

7.  At the Configure the Main Sheet step, specify the Main Sheet File Name as 
Auto_2E.SchDoc and any further options as depicted in Figure 6.  Click Next to continue. 

Figure 6. Main sheet options. 

8.  At the Configure the Sheet Symbol Sheet step, check the Create Sheet Symbol box and 
specify the Sheet Symbol File Name as SL_Top.SchDoc.  Click Finish to complete the wizard. 

Figure 7. Symbol sheet options. 

9.  Use File»Save As to save the two, newly auto­generated schematic sheets 
10.  Use File»Save Project As to save the newly created PCB project into this directory as well. 
11.  The basic schematic files have now been created and are ready for modification according to the 
specific project requirements.  At this point, however, the FPGA project may not appear visibly 
linked to the PCB project.  Right­click on the PCB project in the projects panel and compile the 
design.  The design compiler will automatically change the project structure.

3 ­ 10 
Altium Designer Training Module  FPGA to PCB 

Figure 8. Project Panel after compiling. 

12.  Observe the new structure of the created schematic sheets. 
13.  Save your work. 

1.9  Modifying the auto generated sheet 
Occasionally it may be necessary to perform modifications to the auto generated sheet.  This will 
cause the PCB project to lose synchronization with the FPGA project and the designs will need to be 
resynchronized through the FPGA Workspace Map.  Managing project synchronization is an 
automated but not automatic process and project synchronization can only be performed in one 
direction at one time – ie. design revisions can be propagated from the PCB to the FPGA or vice 
versa but not both ways at the same time.  Extreme caution should be exercised if both the PCB and 
FPGA projects are being worked on in parallel. 
Situations might also occur in which a design never totally synchronizes.  This is commonly caused 
when differences exist in the net naming between the PCB and FPGA schematics, or, when 
additional components are connected to the FPGA for possible future expansion.   The latter 
scenario might include the addition of a connector at the board level that is not yet used in the FPGA, 
and thus not represented in the FPGA design.  If this occurs the PCB and FPGA designs will not 
match and though this may cause the designs to appear out of sync, this will not affect the existing 
functional portions of the design. 

1.10  A word about special function FPGA pins 
Special Function Pins are handled in a special way when creating the auto­generated sheet. 
Extreme care must be observed to ensure their connectivity is maintained.  As a rule of thumb it is 
best to select the “Tie to individual ports” for Special Function Pins even if you don’t intend to use 
them in the final design.  If you need to use an I/O pin that has a special function net label attached 
to it, just remove the special function net label and replace it with the net label for the net that you do 
wish to be connected.  Resynchronize the design as necessary.

3 ­ 11 
Altium Designer Training Module  FPGA to PCB 

Selecting any other option other than the “Tie to individual ports” will cause special function net 
labels to be ripped up or renamed.  Beware! 

1.11  Recreating the autogenerated sheet 
The Synchronize dialog provides a button to Recreate Autogenerated Sheet.  This feature should 
be used under extreme care.  If there are any PCB design changes that are yet to have been 
propagated back to the FPGA project then they can be destroyed once the autogenerated sheet is 
recreated. 

Figure 9. Recreating the autogenerated sheet from the synchronize dialog. 

Recall our previous warning about the nature of special function pins; selecting any other option 
other than the Tie to individual ports will cause special function net labels to be ripped up or 
renamed.  Beware!

3 ­ 12 
Altium Designer Training Module  FPGA to PCB 

2. Maintaining project synchronization 
Maintaining synchronization between an FPGA project and its parent PCB project is greatly 
improved through the internal synchronization mechanisms that operate within Altium Designer.  It is 
important, however, that users understand how this synchronization process works so that they don’t 
inadvertently make design changes that will defeat project synchronization. 

2.1  The FPGA workspace map 
At any given time during the design process, the status of the linking between FPGA and PCB 
projects can be readily checked by launching the FPGA Workspace Map dialog. Access to this 
dialog is provided by choosing the command of the same name from the Projects menu, or by 
pressing the  button on the Projects panel. 
In the example below the FPGA Workspace Map displays the relationships (links) between various 
elements of FPGA and PCB projects and the status of these links – whether the two sides of a link 
are synchronized and up­to­date or whether some action is required to resynchronize them. 

Figure 10. The FPGA workspace map dialog. 

The various elements in the two project types are linked in a logical flow – from a soft core 
microcontroller placed within an FPGA project, to a PCB design document within a linked PCB 
project. Each of the links are summarized below: 

2.1.1  FPGA project – soft processor 
The Soft Processors region of the dialog is purely added for completeness and offers at­a­glance 
information on the core microcontroller(s) that are being used in a particular FPGA project. The link, 
as such, is therefore cosmetic. It will always be displayed as synchronized.

3 ­ 13 
Altium Designer Training Module  FPGA to PCB 

2.1.2  Schematic document (PCB project) – FPGA project 
This link reflects the synchronized status between the FPGA component in the PCB project and the 
appropriate configuration in the FPGA project. When determining the status, the software is looking 
for any net­related changes. 

2.1.3  PCB document – schematic document (PCB project) 
This link reflects the synchronized status between the FPGA Component footprint on the PCB 
document and the FPGA Component symbol on the schematic sheet, both within the PCB project. 

2.1.4  Link status 
A link can appear in one of two colors and hovering over a link will produce a textual description of its 
status: 
­  The green link signifies up to date (i.e. both sides are 
synchronized). No action is required. 
­  The red link signifies that the two sides of the link are not 
fully synchronized (i.e. a design change has been made on 
one side but has yet to be passed to the other). Clicking on 
a schematic­FPGA project link with this status will open the 
Synchronize dialog, from where you can browse and 
match any unmatched ports and pins. 
Figure 11. Determining the link status 

When two elements of the map are shown to be un­synchronized (i.e. the link between them is red), 
clicking on the link or its associated icons will give access to a number of synchronization options. 
The hint that appears when hovering over the link will, where possible, provide information on which 
directions updates should be made in order to achieve synchronization. 
Again, it may be possible for a design to never totally synchronize.  Though this may occur, it is not a 
sign of a failed design; it is merely the method with which the synchronizer evaluates differences 
between the FPGA and PCB projects. 

2.2  The synchronize dialog 
If the FPGA Workspace Map determines that the project is not synchronized, a red link will be 
displayed between the corresponding projects.  Clicking on that link will reveal the Synchronize 
dialog.  This dialog provides an automated means for maintaining synchronization between FPGA 
and PCB projects.  It is important at this point that the reader understand that the process is 
automated but not automatic and some care is required to ensure that recent design changes are not 
overwritten.

3 ­ 14 
Altium Designer Training Module  FPGA to PCB 

Figure 12. The synchronize dialog box 

The Synchronize dialog has two primary regions.  The upper region contains a list of PCB project 
signal names that correspond with FPGA port names.  These signals are referred to as the matched 
signals.  Information concerning the matched signals is further subdivided so that settings relating to 
the Pin number and Electrical Type can easily be compared between the FPGA and PCB projects. 
The lower region contains signals that can’t be matched based on their signal names – otherwise 
known as unmatched signals.  The Synchronize dialog has no option but to request user 
intervention in knowing how to match and/or handle these signals. 
Project synchronization can only be performed in one direction at one time – that is design revisions 
can be propagated from the PCB to the FPGA or vice versa but not both ways at the same time. 
Where it is necessary to work on both the FPGA and PCB projects in parallel, a stub project may 
need to be created to manage synchronization between them.  More information concerning stub 
projects can be found in document AP0102 Linking an FPGA Project to a PCB Project.pdf. 

2.2.1  Determining synchronization status 
How the dialog is populated depends on the extent of net naming in the FPGA component 
schematic. The following is a summary of the possibilities:
· A net label has been assigned to a pin with the same name as that used for the corresponding 
port in the FPGA project. The pin number is different to that (if specified) in the associated 
constraint file and/or the electrical type for the pin is different to that of the port. As the port and 
pin have the same signal name, they will appear in the Matched Signals list. The entry will be 
highlighted in red as the pin number and/or electrical type is different
· A net label has been assigned to a pin with the same name as that used for the corresponding 
port in the FPGA project. The pin number is identical to that in the associated constraint file and 
the electrical type for the pin is identical to that of the port. As the port and pin have the same 
signal name, they will appear in the Matched Signals list. The entry will be highlighted in green 
as the pin number and electrical type are also the same
· A net label has been assigned to a pin with a different name to any of the ports in the FPGA 
project. An entry for the signal name will appear in the Unmatched PCB Signals list.
· All ports that have not been matched to pins with the same name will appear in the Unmatched 
FPGA Signals list.

3 ­ 15 
Altium Designer Training Module  FPGA to PCB 

2.3  Synchronizing matched signals 
In the event that a matched signal has unsynchronized pin or electrical properties, the 
unsynchronized items will appear red: 

Figure 13. Synchronizing matched signals 

The dialog above is highlighting the fact that the pin numbering for a number of signals is not 
synchronized between the FPGA and PCB projects and that there are some unmatched PCB signals 
between the two projects as well.  The Synchronize dialog has matched the signal names between 
the two projects and so the user has two options: 

2.3.1  Update to PCB 
The Update to PCB option will take the information listed in the FPGA columns and propagate it to 
the PCB columns.  In real terms, settings from the constraint file and FPGA schematic will be 
propagated to the PCB Project (i.e. the auto­generated PCB Project file will be updated).  This can 
be seen in the ECO that is generated: 

Figure 14. Running ECO to update the PCB Project documents

3 ­ 16 
Altium Designer Training Module  FPGA to PCB 

2.3.2  Update to FPGA 
The Update to FPGA option will take the value(s) listed in the PCB column and propagate it to the 
PCB column.  In real terms, settings taken from the PCB Project will be propagated to the constraint 
file and / or the FPGA schematic.  This can be seen in the ECO that is generated. 

Figure 15. Running ECO to update the FPGA Project documents 

It is important to remember that updates can only occur in one direction at a time.  It is not possible, 
for instance, for electrical type information to be propagated in one direction and pin numbering 
information propagated in the opposite direction. 

2.4  Synchronizing unmatched signals 
As previously mentioned, PCB project signals that do not have a corresponding port in the FPGA 
project cannot be matched and require further user intervention to be synchronized.  Below we have 
show a similar situation as before in that pin numbering and electrical type information does not 
match between projects however in addition to this the ports have different names.  The 
Synchronize dialog has no option but to request the user change either the PCB or FPGA projects 
manually.  The Synchronize dialog assists in this process by allowing the user to create To Do 
Items that can be exported to the To Do panel. 

Figure 16. Synchronizing unmatched signals

3 ­ 17 
Altium Designer Training Module  FPGA to PCB 

2.4.1  Add nets to PCB 
The Add Nets to PCB button will remove the selected item from the Unmatched FPGA Signals box 
and place a To­Do item that, once exported, will appear as follows: 

Figure 17. Creating an 'Add Net' To­Do item 

2.4.2  Remove ports 
The Remove Ports button will remove the selected item from the Unmatched FPGA Signals box 
and place a To­Do item that, once exported, will appear as follows: 

Figure 18. Creating a 'Remove Port' To­Do item 

2.4.3  Add ports to FPGA 
The Add Ports to FPGA button will remove the selected item from the Unmatched PCB Signals 
box and place a To­Do item that, once exported, will appear as follows: 

Figure 19. Creating an 'Add Port' To­Do item 

2.4.4  Remove nets 
The Remove Nets button will remove the selected item from the Unmatched PCB Signals box and 
place a To­Do item that, once exported, will appear as follows: 

Figure 20. Creating a 'Remove Net' To­Do item 

2.4.5  Rename PCB net to FPGA port 
The  button will remove both selected items from the Unmatched PCB Signals and 
Unmatched PCB Signals boxes and place a To­Do item that, once exported, will appear as follows:

3 ­ 18 
Altium Designer Training Module  FPGA to PCB 

Figure 21. Creating a 'Rename PCB Net' To­Do item 

2.4.6  Rename FPGA port to PCB net 
The  button will remove both selected items from the Unmatched PCB Signals and 
Unmatched PCB Signals boxes and place a To­Do item that, once exported, will appear as follows: 

Figure 22. Creating a 'Rename FPGA Port' To­Do item 

Once To­Do items have been exported, perform the updates manually, save the affected files and 
check the FPGA Workspace Map dialog again to ensure synchronization has been re­established.

3 ­ 19 
Altium Designer Training Module  FPGA to PCB 

3. Configuring FPGA I/O 
The FPGA Workspace Map dialog gives you the ability to check the state of the design across 
linked FPGA and PCB projects and the means to propagate design changes between the two. The 
following sections consider some of the more common design changes that might be made and that 
require use of this dialog to detect such changes and ensure synchronization of the entire design. 
In each case, it is assumed that the two, full design projects are local to the designer – stored on the 
one machine and in the same directory structure. 

3.1  Configuring I/O standards 
FPGA devices generally support a range of I/O standards. These standards follow industry 
specifications and often include options like LVTTL, LVCMOS and PCI to name a few. This enables 
the FPGA to communicate directly with other devices requiring a certain standard. Often the 
standards will also support further customization including the slew rate, current strength and 
voltage. 
Each device will have its own set of supported standards. Only supported standards can be selected 
for the current device. 
There is a complex set of interactions between different I/O standards in an FPGA. Some I/O 
standards will be able to co­exist while others are mutually exclusive. Often the requirements are 
limited to I/O banks, such that all pins within an I/O bank on an FPGA must have compatible I/O 
standards. This becomes particularly important with voltage­referenced standards such as GTL, as 
an I/O bank will generally only be able to support one voltage reference value. 
The interaction of selected I/O standards with one another is not modeled here and vendor 
documentation should be referred to for more detailed information. As a general rule of thumb, 
keeping pins using different I/O standards in separate I/O banks will ensure compatibility. Any errors 
will be picked up when the vendor place & route tools process the design. 

3.1.1  Selecting standards 
I/O standards, slew rates and drive strengths for each pin of an FPGA device can be defined in the 
FPGA Signal Manager dialog. This dialog is accessed by choosing the FPGA Signal Manager 
entry under the Tools menu, from any schematic document within the PCB or FPGA project. When 
accessed from a schematic in the PCB project, if more than one FPGA component is present a 
dialog will appear beforehand listing the components from which to choose. 

Figure 23. FPGA Signal Manager 

Note: the list of available I/O standards is context sensitive ­ only standards that are applicable for 
that particular FPGA will be available.

3 ­ 20 
Altium Designer Training Module  FPGA to PCB 

FPGA signals can be rapidly updated in groups by using the standard shift/ctrl­select technique and 
right clicking one of the selected rows to access the popup menu.  Additional columns can also be 
enabled from this menu. 
After defining the characteristics for the appropriate pins of the device as required, click OK to close 
the dialog. The Engineering Change Order dialog will appear, with the settings you define listed as 
a series of parameters to be added to the affected port constraint entries in the linked constraint file. 

Figure 23. Updating the constraint file with signal manager changes 

These changes are to signal characteristics only – not pin­specific changes. As such, they affect only 
the relevant entries in the associated constraint file. The schematic representation of the FPGA 
component is not affected and launching the FPGA Workspace Map dialog will show the link 
between the schematic component and the FPGA project still green, highlighting the fact that the two 
sides are fully synchronized. 
The changes will be stored as constraints on the ports in the constraint file. Each required change 
will be performed via an ECO and by executing the changes, the new I/O standards will be saved in 
the constraint file. Any future synthesis/build process will then use these constraints for programming 
the FPGA. (These constraints would also be used when performing a Signal Integrity analysis on the 
PCB project). 

3.2  Exercise 2 – Using the FPGA signal manager 
1.  With the Auto_2E.SCHDOC document open, select Tools » FPGA Signal Manager from the 
menu. 
2.  Modify the following signals as described: 
a.  CLK_BRD:  Slew Rate = FAST 
b.  JTAG_NEXUS_TCK: Slew Rate = FAST 
c.  JTAG_NEXUS_TDI: Slew Rate = FAST 
d.  JTAG_NEXUS_TDO: Slew Rate = FAST, Drive Strength = 24mA 
e.  JTAG_NEXUS_TMS: Slew Rate = FAST 
f.  LCD_DB[0..7]: Drive Strength = 24mA.

3 ­ 21 
Altium Designer Training Module  FPGA to PCB 

Figure 234. Updated signals in signal manager 

3.  Select OK to implement the changes and open the Engineering Change Order dialog. 

Figure 25. Committing changes made via the FPGA signal manager 

4.  Validate Changes and Execute Changes and then select Close. 
5.  Check the FPGA Workspace Map to ensure your project is still synchronised. 
6.  Save your work.

3 ­ 22 
Altium Designer Training Module  FPGA to PCB 

4. Manually linking FPGA and PCB projects 
In some circumstances the FPGA design will be developed in parallel with, but separate from, the 
PCB design.  In these situations it may be necessary to manually link the FPGA and PCB designs 
together to ensure synchronization. 

Figure 24. Manually linking FPGA and PCB projects that have been developed separately 

In the event of an unlinked PCB and FPGA project, the FPGA Workspace Map may look something 
like this: 

Figure 25. FPGA workspace map with no link between the PCB and FPGA projects 

Figure 25 shows that the schematic and PCB documents are correctly linked and synchronized, 
however no link currently exists between the FPGA project and the PCB project.  This is apparent by

3 ­ 23 
Altium Designer Training Module  FPGA to PCB 

the lack of connecting lines between the SL1 Xilinx Spartan­IIE PQ208 Rev 1.01.PRJPCB 
and the FPGA projects and also by the comment No linked configuration below the 
FPGA_51_Spirit_Level.PRJFPG icon. 

4.1  Supported devices 
In order for Altium Designer to establish a link between an FPGA project and a PCB project, the 
FPGA component in use by each project must be recognized and supported.  All devices present in 
the vendor libraries are supported for linking. 
The component placed on the schematic sheet has to be verified against the list of supported 
devices in some way, before it is recognized and displayed in the FPGA Workspace Map dialog. 
This is achieved using the Design Item ID field in the Component Properties dialog for the FPGA 
component symbol on the PCB schematic. To be a recognized device, the entry in this field must be 
identical to that in the Device field for the corresponding device in the Choose Physical Device 
dialog. This is demonstrated in Figure 26: 

Figure 26. Verification that device is supported. 

4.2  Creating the link 
Once the FPGA devices have been recognized as supported, it is possible to create the manual link 
between the PCB and FPGA projects.  This is done using the Structure Editor in the Projects panel 
in much the same way as we previously linked an embedded project to an FPGA project. 
The lower region of the Projects panel contains all the valid sub­projects that are open in the 
workspace. This includes FPGA, embedded and core projects. For FPGA projects, their defined 
configurations will also be listed along with constraint files associated to each.  Within this region of 
the panel, constraint files can be moved from one configuration to another, simply by performing a 
drag­and­drop. The constraint file will be disassociated from the source configuration and newly 
associated to the target configuration. To copy a constraint file to another configuration, simply hold 
down the CTRL key whilst performing the drag­and­drop. 
To purely disassociate a constraint file from a configuration, simply drag the entry for the constraint 
into free space within the lower region of the panel. 
Double­clicking on a configuration entry will launch the Configuration Manager dialog for the parent 
FPGA project. 
Linking of the two projects is achieved in one of the following ways:
· Dragging a configuration defined for the FPGA project from the lower region of the Projects 
panel and dropping it onto the entry for the FPGA component in the PCB project
· Dragging the FPGA project – from either the upper or lower regions of the panel – and dropping 
it onto the FPGA component entry in the PCB project

3 ­ 24 
Altium Designer Training Module  FPGA to PCB 

· Right­clicking on the entry for the FPGA component in the PCB project and choosing the Set 
Sub Project command from the pop­up menu that appears. This will open the Select Sub 
Project dialog, from where you can browse to and open the desired FPGA sub­project. This 
method is particularly useful if the desired sub­project is not currently open in the Projects panel. 

Figure 27. Linking two projects via drag­and­drop in the structure editor 

In each case, as you start to drag, the possible FPGA component entries (that reside on a schematic 
sheet(s) within one or more PCB projects) that you can validly drop onto are highlighted in pale blue. 
As the cursor passes onto a valid 'drop zone' it will change from a no­entry symbol to a document 
symbol as shown above. 
If you choose to drag the entire FPGA project entry onto the target schematic FPGA component and 
more than one valid configuration exists for that project – i.e. more than one configuration contains 
an associated constraint file targeting the FPGA device – the Select Configuration dialog will 
appear from where you can choose which specific configuration to use. 

Figure 28. Selecting a configuration to be linked. 

When the required configuration has been assigned, the parent FPGA project will become linked to 
the PCB project and is shown in the structure hierarchy as a sub­design of the schematic FPGA 
component.

3 ­ 25
Altium Designer Training Module  FPGA to PCB 

Figure 29. Structural view of a FPGA project linked to a PCB project. 

To break the link between the two projects, simply click and drag the FPGA project entry into free 
space within the panel (below the last entry). 

Now that a configuration has been linked, the FPGA and PCB projects become linked and the FPGA 
Workspace Map dialog will display a link between the schematic component in the PCB project and 
the FPGA project. 

Figure 30. FPGA workspace map showing the synchronization status of linked projects. 

The projects are now linked, but they are yet to be synchronized.

3 ­ 26 
Altium Designer Training Module  FPGA to PCB 

4.3  Linking an auto generated sheet to an existing PCB project 
If you select the option to Create Sheet Symbol in the last stage of the FPGA to PCB Project 
Wizard a sheet containing a sheet symbol of the FPGA project will be created.  This can be used as 
the basis for building a complete schematic to describe the target PCB hardware. 
Alternatively, if you are working with a PCB project that already exists, you will probably already have 
a sheet with many sheet symbols leading to various other sub­sheets. In this case you may simply 
wish to connect an existing sheet symbol to the auto­generated sheet.  This scenario would likely 
occur where it has been decided to change the FPGA device on an existing PCB design.  In this 
case, you would open the Sheet Symbol dialog for the existing sheet symbol and manually edit the 
Filename field to point to the auto­generated sheet. 

Figure 31. Manually linking an auto generated sheet to a sheet symbol. 

4.4  Exercise 3 – Manually linking a PCB and FPGA project 
1.  Open the SL Rev1.01.PrjPCB and the FPGA_U1\SpiritLevel.PRJFPG projects at the 
same time. 
2.  Open the FPGA Workspace Map and verify that there is no link between the FPGA and PCB 
projects. 
3.  Change to the Structure Editor and establish a link between the PCB and FPGA projects. 
4.  Reopen the FPGA Workspace Map and verify that a link now exists. 
5.  Click on the red link between the FPGA and PCB projects to resolve the unsynchronised signals. 
6.  Save your work.

3 ­ 27 
Altium Designer Training Module  FPGA to PCB 

5. Pin swapping 
5.1  Pin swapping in the PCB document 
Many people may wonder why separate Auto and Manual schematic files are created in the FPGA 
to PCB Project Wizard process.  The Auto file creates the actual FPGA schematic symbol and links 
the relevant pins to ports.  The Manual file contains a sheet symbol that contains all of the ports 
defined in the Auto file.  The port linkage between the Auto and Manual files is a logical one rather 
than physical.  This abstraction makes it possible for the tool to perform pin swapping on the Auto 
schematic without affecting connectivity on the Manual file. 
The port­to­physical pin assignments for an FPGA device are defined in a constraint file. You can 
manually define the assignments, or let the place and route tools assign them and then import the 
assignments back into the constraint file. However, once the FPGA is placed on the PCB, pin 
assignments often need to be changed in order to optimize the PCB routing and then these changes 
back­annotated to the FPGA project, to keep the two projects synchronized. 

5.1.1  Setup – Pin swapping methods 
There are two ways that pin swaps can be represented at the schematic level. These are controlled 
from the Options tab of the project options dialog box.  In both cases, the actual wiring on the 
schematic will not be altered; just its connectivity. 

Figure 32. Setting pin and part swapping methods. 

Adding / Removing Net­Labels will move net labels on the swapped pins or nets to reflect the 
changes that were made during pin swapping.  In this case, the schematic symbol will be left 
unchanged. 

Changing Schematic Pins will allow Altium Designer to move the pins on schematic symbols 
according to the pin swaps performed at the PCB level. 

Where both options have been checked, Altium Designer will default to swapping net labels.  If no 
labels exist on the nets, it will swap pins on the schematic symbols.

3 ­ 28 
Altium Designer Training Module  FPGA to PCB 

5.1.2  Setup – Swap groups 
Before pins can be swapped with each other, it is important to first set up swap group IDs, as it may 
not be desirable (or acceptable) for all pins to be swapped with one another. While all I/O pins within 
an FPGA can theoretically be swapped to give a better layout for routing, conditions may dictate 
otherwise. Firstly, some pins have additional special functions (clock pins, config pins and VREF pins 
to name a few), and it may be preferable to reserve these for their special purpose. Secondly, setting 
limitations here will allow any swapping process to obey the banking and I/O standards requirements 
as described earlier. For this reason, it may be desirable for pins in a certain bank to only be 
swappable with each other (or perhaps other banks with compatible I/O standards). 

Swap groups may be defined at schematic or PCB level, as described below. 

Setting swap groups in the schematic 
To define swap groups in the schematic level, select the Tools » Configure Pin Swapping option. 
The resulting dialog box will list all components in the design. 

Figure 33. Setting up swap groups for various components. 

Select the component you wish to define swap groups for and click on the Configure Component 
button or simply double­click the component in the list to access the Configure Pin Swapping For 
… dialog.

3 ­ 29 
Altium Designer Training Module  FPGA to PCB 

Setting swap groups in the PCB
· Right­click the component you wish to set up for pin swapping and select the Component 
Actions >> Configure Pin / Part Swapping … .
· Select the Tools >> Pin / Part Swapping >> Configure option to access the Configure 
Swapping Information In Components dialog box (see figure above).  Select the 
component you wish to define swap groups for and click on the Configure Component 
button to access the Configure Pin Swapping For … dialog. 

Figure 34. Specifying swap group IDs in the pin swap manager. 

All pins with the same swap group ID can be freely swapped.
· Assign each I/O pin on the device to the required swap group. Either manually enter the label for 
the group directly in the Swap Group ID field, or use the right click menu to assign swap groups 
by various pin attributes. 

5.1.3  Setup – Enabling components for pin / part swapping 
Once swap groups have been defined, one more step is required before the actual pin swap.  Altium 
Designer will only swap pins for components which have been specifically marked as allowing pin 
swapping.  To do this for a given component, select it in PCB mode and view the component’s 
properties.  Then, under swapping options, make sure that Enable Pin Swaps has been enabled. 
Do this for each component that requires pin swapping.

3 ­ 30 
Altium Designer Training Module  FPGA to PCB 

Figure 35.Enabling pin swaps for a component. 

5.1.4  Swapping 
Having defined the Swap Group IDs as appropriate, the actual process of swapping pins can now be 
performed. With the PCB document active, simply click on the Pin/ Part Swapping entry under the 
Tools menu and choose a method to swap pins. 
The Automatic Net/Pin Optimizer may be used on any or all components in a document and is not 
limited to FPGA components. This pin swapper will attempt to find the optimal pin allocations for 
routing, whilst obeying the pin swap Group IDs previously set up.  It runs through a two­stage 
process: the first stage is a fast single­pass optimizer that will attempt to minimize crossovers and 
connection lengths, while the second stage is an iterative optimizer which performs multiple passes. 
The second stage is optional, as the time required for the iterative process increases significantly 
when attempting to optimize multiple components.

3 ­ 31 
Altium Designer Training Module  FPGA to PCB 

Figure 36. Rats nest prior to automated pin swapping 

The two PCB snapshots depicted above and below show how the auto pin swapping tool can be 
used to great effect to obtain an optimized set of pin allocations from which to route. In this case, all 
I/O pins on the FPGA device have been assigned the same swap group ID. 

Figure 37. Unraveled rats nest after automated pin swapping 

The Interactive Pin/Net Swapping tool allows for fine­tuning and gives the power to make any 
number of individual pin swaps – again, in accordance with the pin swap group IDs already 
configured. 
A sequence of swapping processes can be performed. For example, the automatic tool may be run 
initially and then the interactive tool used afterwards to fine­tune a couple of out of place nets/pins. 
If any FPGA components in the design are linked, due to the design being multi­channel in nature, 
(e.g. U1_X1, U1_X2), they must be optimized together. When using the interactive pin swapping 
tool, swapping can not be carried out on the linked component and a dialog will appear alerting you 
to this fact. For example, if U1_X2 is linked to U1_X1, both components must be optimized together, 
but manual pin swapping can only be carried out on U1_X1.

3 ­ 32 
Altium Designer Training Module  FPGA to PCB 

A pin swap operation achieves two things. Firstly it copies the important properties from the new pin 
– this will be the electrical type of the pin as well as any parameters on that pin. Secondly it will 
add/rename/remove an attached net label for that pin as appropriate. Note that this second step can 
only occur if the FPGA component schematic sheet has been autogenerated using the FPGA To 
PCB Project Wizard or has been created using a similar design style. 

After updating the PCB, the changes need to be propagated to the rest of the project.  To update the 
PCB schematics, go to Design >> Update ….  Once updated, you can then use the FPGA 
Workspace Map to propagate the new changes into the FPGA project. You will notice that the 
schematic­FPGA project link appears out of date. 

Figure 38. Re­synchronizing the PCB/FPGA project link after pin swapping 

Clicking on this link will bring up the Synchronize dialog, with the affected (swapped) pins 
highlighted in red, as shown below. 

Figure 39. Managing synchronizations between PCB and FPGA projects

3 ­ 33 
Altium Designer Training Module  FPGA to PCB 

Click on the Update To FPGA button to push the changes to the FPGA project, or more specifically, 
the appropriate FPGA constraint file. The update will consist of a number of parameter change ECOs 
(appearing as a series of change parameter value modifications in the Engineering Change Order 
dialog). 

Figure 40. Confirm ECOs 

Despite having passed the design changes through from the PCB project to the FPGA project, the 
FPGA Workspace Map dialog will not show the designs as being fully synchronized.  This is 
because FPGA signals have been renamed with different net names in the PCB project.  Also, the 
PCB design contains additional connections not represented at the FPGA level (for alternate FPGA 
implementations).  This does not mean that functionally the two designs will not work but rather that 
in its current implementation, these two designs have some differences not related to the 
functionality. 

Figure 41. Fully synchronized PCB/FPGA project 

Important: After pin swapping has been carried out on the PCB, the changes pushed through to the 
FPGA project and the projects re­synchronized, the vendor place & route tools must be run again 
(Build stage in the Devices view). This is because the pin swap information has been updated in the 
constraint file only and now needs to be physically applied to the FPGA device. Running the place & 
route tools again will ensure the new pin assignments are used in an updated FPGA programming 
file.

3 ­ 34 
Altium Designer Training Module  FPGA to PCB 

5.2  Pin swapping in the FPGA project 
Pin swaps initiated from the FPGA project are likely to be required when a design no longer fits 
within the FPGA device. The design may fit however, if existing pin constraints are relaxed and the 
vendor tools are permitted to assign various pin numbers. 
The constraint file can be edited to remove the pin number constraints as required. 
After this process is completed and the design successfully fits again, the new vendor report file will 
need to be imported. 
With the appropriate constraint file open as the active document, select Import Pin File from the 
Design menu. The newly created vendor report file will appear as an entry in the corresponding sub­ 
menu. Importing this file will update the constraints as necessary. 
The changes made to the constraint file now need to be pushed back to the PCB project. This 
process is the reverse of that discussed in the previous section, with all changes again propagated 
from within the FPGA Workspace Map dialog. 
Entering the FPGA Workspace Map dialog will show the schematic­FPGA project link out of date. 
Clicking on this link will bring up the Synchronize dialog, with the affected pins highlighted in red, as 
shown in below: 

Figure 42. Managing synchronizations between PCB and FPGA projects 

Click on the Update To PCB button to push the changes to the PCB project. This will perform a 
series of pin swap operations (using ECOs) on the schematic document. 
Performing these changes will then make the PCB­schematic link out of date (if PCB components 
exist at this stage). Clicking the relevant link will update the PCB document by changing the nets of 
the newly swapped pins (again using ECOs, see below). Further changes may still be required to the 
PCB document if these pins/nets contained any routing.

3 ­ 35 
Altium Designer Training Module  FPGA to PCB 

Figure 43.Confirm ECOs 

5.3  Pin swapping in both PCB and FPGA projects 
It may be that pin changes have been made in both the PCB project and FPGA project without a 
synchronize occurring. If this is the case, entering the FPGA Workspace Map dialog will show the 
schematic­FPGA project link out of date (Red). 
Clicking on the link will open the Synchronize dialog, with all differences highlighted in red. It is not 
possible to pass the relevant changes in their respective directions (PCB to FPGA and FPGA to 
PCB) simultaneously. The sequence for passing the changes as required and resynchronizing the 
link is summarized as follows:
· First choose the initial direction in which to pass changes, by clicking on either the Update To 
PCB or Update To FPGA buttons
· In the Engineering Change Order dialog that appears, all changes will be geared to the chosen 
direction. Enable only those modifications that are required for that direction.
· Execute the changes
· When the Synchronize dialog reappears, click on the Update button that was not initially 
pressed, in order to pass changes in the second of the two directions
· Execute the changes in the subsequent Engineering Change Order dialog that appears 
The Synchronize dialog will reappear, showing no differences in the Matched Signals list 
(appearing totally green). In the FPGA Workspace Map dialog, the link will have returned to its fully 
synchronized status (Green). 

5.4  Exercise 4 – Pin swapping 
This exercise continues on from work done in the previous exercise. 
1.  Open SL Rev1.01 NoRoutes.PcbDoc. 
2.  Check the Adding / Removing Net Labels option in the options tab of the project options dialog 
box.  Leave the Changing Schematic Pins option unchecked.  Click OK to close the project 
options dialog. 
3.  Select Tools » Pin/Part Swapping » Configure… 
4.  Select the FPGA component, and Configure Component 
5.  Ensure Show I/O Pins Only is selected from the dropdown list on the bottom left of the dialog 
box. 
6.  Create a unique Swap Group ID for each of the following signals: 
a.  I\N\I\T\ 
b.  DIN 
7.  All other IO pins can be placed into a single swap group called ‘general_IO’.

3 ­ 36 
Altium Designer Training Module  FPGA to PCB 

Figure 44. Specify swap group IDs for all of the IO 

8.  Select OK. 
9.  Zoom in to view the FPGA device in the centre of the PCB. 
10.  Double click on the FPGA device.  When the Component U1 dialog appears, change the 
Rotation to 180 degrees and click OK. 
11.  Use the automatic pin swapping to rearrange the pins. 
12.  Wait for a moment for the system to perform the pin swapping. 
13.  Go to the Design menu, and select Update Schematics to bring the changes across to the PCB 
schematics. 
14.  Open the FPGA Workspace Map, and resolve any unsynchronised signals.  The PCB should be 
the master document at this stage so select Update to FPGA when performing any changes. 
15.  Save your work.

3 ­ 37 
Altium Designer Training Module  FPGA to PCB 

6. Commissioning the design 
One of the advantages of having a hardware platform such as the Desktop NanoBoard at your 
disposal during development is that you can perform a staged migration of the design onto a custom 
target PCB.  Even if components for the target have not yet arrived, initial commissioning can begin 
by coupling the target to the NanoBoard and using NanoBoard resources as a substitute for the 
missing components. 

6.1  Exercise 5 – Migration stage 1 
In this exercise, we consider the scenario where one or more of the target resources are yet to be 
placed.  In this case we may choose to run the main application from the target board but use 
peripherals available on the NanoBoard to test our application.  For this exercise to function correctly 
we will need to load designs on to both the NanoBoard and Target platforms. 
1.  Locate the ..\Module 3\Exercise 5\ directory and load 
SL Rev1.01.PrjPCB as well as FPGA_NB\SpiritLevel_NB.PRJFPG 
2.  Observe the contents of the schematic document SL_FPGA_NB.SchDoc.  Notice how the 
NEXUS JTAG Connector needs to be present and the TDI / TDO loop made to ensure that the 
JTAG soft chain is not broken within the NanoBoard device. 
3.  Switch off the Desktop NanoBoard and target board power. 
4.  Using a 10­pin ribbon cable, connect HDR1 on the target board to USER BOARD A on the 
NanoBoard. 
5.  Using a 20­pin ribbon cable, connect HDR2 on the target board to USER HEADER A on the 
NanoBoard. 
6.  Ensure the X­axis jumper is removed from the target board. 
7.  Ensure all DIP Switches on the target board are set to the ON position. 
8.  Place the CONFIG jumper on the target board. 
9.  Switch on the NanoBoard and target board. 
10.  Open the Devices view and verify the existence of two FPGA devices (and one configuration 
device) in the Hard Chain.  The first device will always be the NanoBoard device. 
11.  Build and download the SpiritLevel_NB / NB_Base configuration to the NanoBoard device. 
12.  Build and download the SpiritLevel / Tgt_Spartan2 configuration to the target board 
device. 
13.  Observe the status of the Processor in the soft chain.  If, after downloading both projects, this 
device is listed as Missing, it is likely the soft chain is broken somewhere.  Verify that a loop 
between JTAG_NEXUS_TDI and JTAG_NEXUS_TDO exists on the SL_FPGA_NB.SchDoc. 
Rebuild the project if necessary. 
14.  Set the NanoBoard clock frequency to 6 MHz and ensure that DIP Switch 8 on the NanoBoard is 
ON.  Observe the display on the target board.  Assert one or two of the NanoBoard’s lower DIP 
Switches and see what change occurs in the Target’s LCD.  If the target board LEDs are not 
flashing then this indicates it is not receiving a signal from the NanoBoard.  Ensure all outputs 
from the Digital IOB on the target board are 0 and check the wiring between the NanoBoard and 
the target board.  Also ensure the respective projects have loaded correctly.

3 ­ 38 
Altium Designer Training Module  FPGA to PCB 

Figure 45. Devices view with all devices correctly connected and programmed. 

Figure 46. Devices view after all devices have been programmed but with broken soft chain 

6.2  Exercise 6 – Migration stage 2 
In this final stage, we will remove the NanoBoard from the loop and run the design completely from 
the target board.  This exercise will follow on directly from the previous one. 
1.  Close the SpiritLevel_NB.PRJFPG project. 
2.  Ensure that both the Desktop NanoBoard and target board are switched off. 
3.  Remove the daughter board from the NanoBoard. 
4.  Disconnect the 20­pin ribbon cable but leave the 10­pin cable connected. 
5.  Ensure the X axis jumper is in place on the target board. 
6.  Ensure the CONFIG jumper is in place on the target board. 
7.  Apply power to both the NanoBoard and target board. 
8.  Build and download the SpiritLevel / Tgt_Spartan2 configuration to the target board 
device. 
9.  Once the design is loaded, try tilting the target board and observe the LCD. 
10.  Note the existence of a number of downloadable instruments present in the target device.  Note 
that they are fully functional on the target device and don’t require the presence of the 
NanoBoard. 

6.3  Exercise 7 – Calibration 
Some of the target boards will not display a zero reading when placed on a level surface.  In this 
exercise we will show how to calibrate this error out.  This exercise flows on from the previous 
exercise and uses the same source files. 
1.  Ensure that the project from the previous exercise has been loaded and is operational. 
2.  Open TimeTSK51.C  and locate lines 93 and 94.  Try a nonzero number (between 1 and 255) to 
apply a calibration factor. Remember to use the ‘Compile and Download’ button to quickly rebuild 
and run the software.

3 ­ 39 
Altium Designer Training Module  FPGA to PCB 

Figure 47.  Applying a calibration factor by hard coding it into the source code 

3.  Iteratively try to find the best calibration factor to produce a zero reading on a flat, level surface. 
4.  Save your work. 

6.4  Exercise 8 – Bootstrapping the FPGA 
An FPGA design is not much good if every time the board is powered up it needs to be connected to 
some programming device to configure the FPGA.  The spirit level application was designed to 
operate as a stand­alone system and so it needs some means for storing the FPGA configuration 
when power is removed.  For this purpose, a serial configuration device has been installed on the 
target board.  On power up, the FPGA device observes that it is connected to the configuration 
device and automatically configures itself from the device.  In this final exercise we will program the 
configuration device and make the spirit level a truly self­contained embedded system.  This exercise 
flows on from the previous one.  Any calibration factors incorporated into the source code will be 
included in the device configuration. 
1.  Ensure that the project from the previous exercise has been loaded and is operational. 
2.  If the Make PROM File step in the Build flow is currently greyed out, enable this step by clicking 
on its options icon and specify the appropriate configuration PROM device. 

Figure 48.  Specifying the configuration PROM device 

3.  Select the mcs option under the Format drop down. 
4.  Rebuild the entire project to ensure that your calibration values are included in the build and the 
configuration PROM file gets created.

3 ­ 40 
Altium Designer Training Module  FPGA to PCB 

Right­click on the configuration device in the hard chain and select Choose File and Download… 
from the popup menu. 

Figure 49.  Downloading a PROM to the configuration device. 

5.  Locate the MCS bitfile.  You will find it under 
\ProjectOutputs\Tgt_Spartan2\spiritlevel.mcs.  Once you select it, downloading 
will begin immediately. 
6.  The programming process may take several seconds as the device has to first be erased before 
it can be programmed.  When asked if you wish to verify programming select Yes.  Be sure not 
to remove power from the device until programming is complete.  You will be notified of 
successful programming with the following information dialog. 

Figure 50.  PROM file programming confirmation 

7.  Remove power from the target board. 
8.  Disconnect the 10­pin USER BOARD ribbon cable from the target board. 
9.  Remove the CONFIG jumper from the target board but make sure the X­axis jumper remains 
connected. 
10.  Reapply power to the target board and verify that the application correctly loads and runs itself. 
11.  Switch off the NanoBoard and the target board and reconnect the 10­pin USER BOARD ribbon 
cable between the target board and the NanoBoard. 
12.  Reapply power to the target board and NanoBoard and observe in the Devices view that the 
downloadable instruments are still accessible. 

6.5  Exercise 9 – Reverting to test mode 
1.  To ensure the target boards are left in a state ready for the next users, it will be necessary to 
reprogram the PROM with the Test Mode configuration file.  You will find this file as 
\Exercise9\ConfigTest.mcs.  Use the steps outlined in the previous exercise to program 
this test file back into the PROM.

3 ­ 41 
Altium Designer Training Module  FPGA to PCB 

7. Review

3 ­ 42