Altium FPGA To PCB

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, PCAD, 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. HPGL 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
FPGA Design Basics
1 FPGA Design......................................................................................................... 11
1.1 Learning objectives..................................................................................... 11
1.2 Topic outline............................................................................................... 11
2 Introduction to FPGA Design ............................................................................... 12
2.1 FPGA basics .............................................................................................. 12
3 Creating an FPGA project..................................................................................... 13
3.1 Overview.................................................................................................... 13
3.2 A quick word about projects and design workspaces................................... 13
3.3 FPGA project.............................................................................................. 14
4 FPGA schematic connectivity.............................................................................. 15
4.1 Overview.................................................................................................... 15
4.2 Wiring the design........................................................................................ 15
4.3 Including HDL source files in a schematic................................................... 15
4.4 Establishing connectivity between documents............................................. 15
4.5 Using buses and bus joiners....................................................................... 16
5 FPGA ready schematic components ................................................................... 19
5.1 Overview.................................................................................................... 19
5.2 Processor cores ......................................................................................... 19
5.3 Desktop NanoBoard port plugins .............................................................. 110
5.4 Peripheral Components ............................................................................ 110
5.5 Generic components ................................................................................ 110
5.6 Vendor macro and primitive libraries......................................................... 110
5.7 Exercise 1 – Create a PWM...................................................................... 111
6 Targeting the design........................................................................................... 113
6.1 Constraint files ......................................................................................... 113
6.2 Configurations .......................................................................................... 114
6.3 NanoBoard constraint files........................................................................ 114
6.4 Configuration Manager ............................................................................. 114
6.5 Auto Configuring an FPGA project ............................................................ 115
6.6 Defining constraints manually ................................................................... 115
6.7 Editing a constraint file.............................................................................. 116
6.8 Exercise 2 – Configuring MyPWM............................................................. 117
7 Running the design ............................................................................................ 119
7.1 Overview.................................................................................................. 119
7.2 Controlling the build process..................................................................... 119
7.3 Understanding the build process............................................................... 120
7.4 Button regions .......................................................................................... 120
7.5 Accessing stage reports / outputs ............................................................. 121
7.6 Build stages.............................................................................................. 121
7.7 Configuring a build stage .......................................................................... 124
7.8 How Altium Designer interacts with backend vendor tools........................ 125
7.9 Exercise 3 – Run MyPWM on the NanoBoard........................................... 125
8 Embedded instruments ...................................................................................... 126
8.1 Overview.................................................................................................. 126
8.2 OnChip debugging .................................................................................. 126
8.3 CLKGEN .................................................................................................. 127
8.4 CROSSPOINT_SWITCH.......................................................................... 127
8.5 FRQCNT2 ................................................................................................ 127
i
8.6 IOB_x....................................................................................................... 128

8.7 DIGITAL_IO ............................................................................................. 128
8.8 LAX_x ...................................................................................................... 129
8.9 Terminal Console ..................................................................................... 131
8.10 Exercise 4A – Using embedded instruments............................................. 131
8.11 Where are the Instruments? ..................................................................... 135
8.12 Enabling embedded instruments............................................................... 135
9 Interacting with the NanoBoard ......................................................................... 137
9.1 Overview.................................................................................................. 137
9.2 NanoBoard communications..................................................................... 137
9.3 Technical background .............................................................................. 138
9.4 The NanoBoard controller......................................................................... 140
9.5 FPGA I/O view.......................................................................................... 141
9.6 Live cross probing .................................................................................... 142
9.7 Exercise 4B – View MyPWM on the NanoBoard ....................................... 142
10 Creating a core component................................................................................ 143
10.1 Core project.............................................................................................. 143
10.2 Creating a core component from an FPGA project .................................... 143
10.3 A word about EDIF ................................................................................... 144
10.4 Setting up the core project ........................................................................ 144
10.5 Constrain / configure ................................................................................ 145
10.6 Creating a new constraint file.................................................................... 146
10.7 Creating a configuration............................................................................ 147
10.8 Synthesize ............................................................................................... 148
10.9 Publish ..................................................................................................... 149
10.10 Creating a core schematic symbol ............................................................ 149
10.11 Using a core component........................................................................... 151
10.12 Exercise 5 – Create a core component from MyPWM ............................... 152
11 FPGA design simulation..................................................................................... 153
11.1 Creating a testbench ................................................................................ 153
11.2 Assigning the Testbench Document.......................................................... 153
11.3 Initiating a simulation session ................................................................... 154
11.4 Project compile order................................................................................ 154
11.5 Setting up the simulation display............................................................... 155
11.6 Running and debugging a simulation ........................................................ 156
11.7 Exercise 6 – Create a testbench and simulate MyPWM ............................ 158
12 Review................................................................................................................. 159
ii
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 FPGAbased 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
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 highspeed 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 nonvolatile 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 highend 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 highend 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 multivendor 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
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 toplevel
project is a PCB project called SL1 Xilinx SpartanIIE
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
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
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 subdocuments are referenced in the same way as schematic subsheets, by
specifying the subdocument 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 subdocument connect to sheet entries of the same name in
the sheet symbol that represents that document, as shown below.
1 5
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 reordered, 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 JBtype 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, 8bit bus.
J8B_8S: describes a bus joiner that routes a single, 8bit bus into 8 single wires.
J8B_4B2: describes a bus joiner that routes a single 8bit bus into two 4bit busses,
J4B4_16B: describes a bus joiner that routes four, 4bit busses into a single 16bit bus.
1 6
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 8bit bus on pin I[7..0]
into two 4bit 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 4bit slices into a 16bit bus. With
this joiner IA0 connects to O0, and ID3 connects to O15.
4.5.3 Matching buses of different widths using the
JBtype bus joiner
Figure 9. Bus joiners
The JBtype 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 nettonet mapping
Read the flow of nets through a JBtype 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 subset 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
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:
Figure 14. Another example of using a bus joiner for range inversion
· In Figure 14 the matching is:
1 8
5 FPGA ready schematic components
5.1 Overview
A wide variety of FPGAready 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 FPGAready schematic
components are like traditional PCBready
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 FPGAready 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 – 32bit 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 Virtex2 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 ARM7based discrete processors from NXP
1 9
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 pinwide and buswide
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 subfolders 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 retargeted to
another vendor’s device.
1 10
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 PortPlugin.IntLib CLOCK_BOARD
CLK_BRD
FPGA NB2DSK01 PortPlugin.IntLib TEST_BUTTON
TEST_BUTTON
ON
SW[7..0] FPGA NB2DSK01 PortPlugin.IntLib DIPSWITCH

1 2 3 4 5 6 7 8
LEDS[7..0] FPGA NB2DSK01 PortPlugin.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
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
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 retargeting 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 porttopin 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
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 rightclicking 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
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
rightclick 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
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
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
4. The autoconfiguration process deals with the mapping of ports defined on the toplevel 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
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 selfcontained 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 leftclick 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
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
7.4.4 Show substages
Selecting the ‘down arrow’ will expose a drop down list of the various substages for the current build
stage. The status of the various substages is indicated by the color of the status ‘LED’. Where a
substage has failed, the associated report file can be examined to help determine the cause of the
failure.
Figure 32. Substages 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 Nexusenabled device
entries in the Soft Devices region of the Devices view.
1 21
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 toplevel 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 autogenerated
and synthesized (e.g. a block of RAM wired to an OCDversion 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 toplevel 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 toplevel folder for System presynthesized models is the \Program Files\Altium
Designer 6\Library\Edif folder, which is subdivided by Vendor and then further by device
family.
· The toplevel 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
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 toplevel 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 lowlevel 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
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 Nexusenabled 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 substages 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 nonvolatile 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
7.8 How Altium Designer interacts with backend 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 backend 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 wellproven
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 cocoordinating programs that simply pass the appropriate parameters
to backend, commandline programs.
When it comes to FPGA targeting, Altium Designer operates in a similar fashion in that it acts as a
coordinator of backend, vendorspecific programs. Parameters that need to be passed from the
Altium Designer frontend to the vendorspecific backend programs are handled by a series of text
based script files. Users who are already familiar with the backend processing tools may find some
use in accessing these script files should they wish to modify or ‘tweak’ interaction with backend
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 vendorspecific backend 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 XC3S15004FG676C 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
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 onchip testing and
debugging.
8.2 OnChip 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 doubleclicking their
associated icon in the Devices View.
1 26
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 designtime configuration, but can be changed onthe
fly at runtime, 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
8.6 IOB_x
Figure 47. Digital IO module, used to monitor and control nodes in the design
The digital I/O is a generalpurpose tool that can be used for
both monitoring and activating nodes in the circuit. It is
available in either 8bit wide or 16bit 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 generalpurpose 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 16bits. 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
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 offchip
memory (e.g. Desktop NanoBoard Memory).
After placing the configurable LAX from the library, rightclick 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
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
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 Wishbonecompliant 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
3. Doubleclick 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
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
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 marktospace
ratio.
Figure 63. Logic analyser setup options.
Figure 64. Logic analyzer waveform with bit7 of the IOB set.
Figure 65. Logic analyzer waveform with bits 6 & 7 of the IOB set.
1 34
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 PortPlugin.IntLib Integrated Libraries.
1 35
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
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
easytouse 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
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
I
JT
J TA
AG
G
P
P a a rr a
a ll ll e
e l Ce
C el
ll
l
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 builtin selftest 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
· 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
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 IEEEISTO and changed their name to the Nexus 5001
Forum and released V1.0 of IEEEISTO – 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 lowlevel 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 doubleclicking 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 nonstandard frequency is possible by clicking the Other Frequency button. The
NanoBoard clock system employs a serially programmable clock source (part number ICS30702)
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 nonvolatle user data. The
Embedded Memory device is accessible via the SERIALFMEMORY component in the FPGA
NB2DSK01 PortPlugin.IntLib Library.
1 40
9.5 FPGA I/O view
To display the Instrument rack for a device, doubleclick 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
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
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 selfcontained 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
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
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 retargeting 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
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 selfcontained 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
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 Spartan3 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:
· Rightclick 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
· 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
· 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
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
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
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
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 dropdown list.
Figure 9218. Specifying the testbench document
1 53
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
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
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 userspecified 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 sequentiallybased
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 singlestep 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
Figure 98. The simulation debugger options in the preferences dialog.
1 57
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, toplevel entity/configuration and toplevel 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
12 Review
1 59
Designing Systems on FPGAs
11
Document Version 1.2, April 2008
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, PCAD,
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. HPGL 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
12
1 Designing a System to Display Video ..................................................................15
1.1 The nuts and bolts of capturing video..........................................................15
1.2 The nuts and bolts of Displaying video on a touch screen............................16
1.3 A high level view of our system ...................................................................16
2 Utilizing microprocessor softcores......................................................................27
2.1 How soft is a softcore?................................................................................27
2.2 Using a softcore in an FPGA schematic ......................................................28
2.3 Accessing softcore datasheets....................................................................28
2.4 The TSK3000 Processor .............................................................................28
2.5 Exercise 1 – Placing a softcore onto an FPGA schematic............................29
2.6 Configuring the TSK3000 processor............................................................29
2.7 Exercise 2 – Configuring the TSK3000A Processor ...................................211
3 Wishbone Interconnection Architecture ............................................................312
3.1 Wishbone compatible cores ......................................................................312
3.2 Wishbone interface signal descriptions......................................................313
3.3 Pin naming conventions for wishbone signal pins......................................315
4 Placing the FPGA Peripherals ............................................................................417
4.1 Exercise 3 – Placing the peripherals .........................................................417
5 Bus Interconnectivity and Arbitration ................................................................520
5.1 Wishbone Interconnect Component WB_INTERCON................................520
5.2 Configuring the Wishbone Interconnect component...................................521
5.3 Exercise 4 – Connecting our Peripherals...................................................524
5.4 Managing memory access ........................................................................525
5.5 Arbitration of multiple masters sharing a single slave.................................525
5.6 Wishbone Dual and Multi Master devices................................................526
5.7 Configuring the wishbone multi master component...................................527
5.8 Exercise 5 – Defining our Multi Master Components..................................530
6 Interfacing to External Memory ..........................................................................631
6.1 Configuring the SRAM Controller ..............................................................631
6.2 The Shared Memory Controller .................................................................633
6.3 Configuring the Shared Memory Controller................................................634
6.4 Exercise 6 – Placing and configuring memory controllers ..........................636
6.5 Exercise 7 – Multiple memories as slaves .................................................637
6.6 Exercise 8 – Placing the Port Plug In Components....................................638
6.7 Exercise 10 – Wiring Up Your FPGA Design .............................................640
7 Configuring Processor Memory .........................................................................742
7.1 Dividing the processor memory .................................................................743
7.2 Exercise 11 – Configuring the processor memory......................................745
7.3 Configuring processor peripherals.............................................................746
7.4 Exercise 12 – Specifying processor peripherals.........................................747
8 Finalizing the Design, Compiling and Resolving Errors....................................848
9 Creating Embedded Systems on FPGAs ...........................................................949
9.1 Exercise 13 – Editor Basics.......................................................................949
9.2 The TASKING tool chain...........................................................................953
9.3 The Build flow ...........................................................................................953
9.4 Targeting the Project.................................................................................954
9.5 Project options..........................................................................................954
9.6 Attaching an embedded project to an FPGA project ..................................966
9.7 Exercise 13 – Linking projects...................................................................968
9.8 Exercise 14 – Building our design .............................................................968
9.9 Exercise 15 – Updating our software Live..................................................970
10 Updating the Design to Display Video ............................................................. 1071
10.1 Defining Sections.................................................................................... 1071
10.2 Exercise 16 – Updating our software Live................................................ 1072
13
10.3 Exercise 17 – Updating our Software to Capture Video ........................... 1073
10.4 Utilizing the Virtual Instruments ............................................................... 1074
10.5 Using instruments to control our design................................................... 1074
10.6 Exercise 18 – Updating the Wishbone Port IO......................................... 1075
10.7 Exercise 19 – Adding the Virtual Instruments .......................................... 1076
10.8 Exercise 20 Rebuilding the project with instruments .............................. 1078
10.9 Updating our embedded project to use the instruments ........................... 1078
10.10 Exercise 21 – Adding Additional Source Files.......................................... 1078
10.11 Exercise 22 – Updating main.c................................................................ 1078
10.12 Exercise 23 – Controlling our design with instruments ............................. 1079
11 Realtime Debugging of a Processor ............................................................... 1181
11.1 OnChip Debugging ................................................................................ 1181
11.2 A word about simulation.......................................................................... 1181
11.3 Embedded control panels........................................................................ 1183
11.4 Instrument Rack – Nexus Debugger........................................................ 1189
12 C to Hardware.................................................................................................... 1292
12.1 What are the benefits of the CtoHardware Compiler?............................ 1292
12.2 Using the CHC Compiler......................................................................... 1292
12.3 Implementing C to Hardware in our Design ............................................. 1293
12.4 Exercise 24 – Making Room for C to Hardware ....................................... 1293
12.5 Exercise 25 – Adding the Application Specific Processor......................... 1294
12.6 Exercise 26 – Giving the ASP Access to Memory (part 1)........................ 1295
12.7 Exercise 27 – Giving the ASP Access to Memory (part 2)........................ 1297
12.8 Configuring the ASP ............................................................................. 12101
12.9 Exercise 28 – Accelerating our performance with ASP .......................... 12103
13 OpenBus.......................................................................................................... 13106
13.1 Creating an OpenBus version of our design .......................................... 13106
13.2 Exercise 29 – Beginning an FPGA Project Using OpenBus ................ 13106
13.3 OpenBus Devices ................................................................................. 13107
13.4 Exercise 30 – Placing Open Bus Components (part 1) .......................... 13107
13.5 Exercise 31 – Using an Interconnect ..................................................... 13111
13.6 Exercise 32 – Linking OpenBus Ports ................................................... 13114
13.7 Exercise 33 – Configuring our processor under open bus...................... 13115
13.8 Exercise 34 – Configuring the GPIO Component................................... 13115
13.9 Exercise 35 – Finalizing the Interconnect Component ........................... 13116
13.10 Defining the Memory Side of our System............................................... 13117
13.11 Exercise 36 – Adding the Remaining Components ................................ 13117
13.12 Exercise 37 – Completing the Connectivity............................................ 13118
13.13 Exercise 38 – Configuring the SRAM Controllers................................... 13118
13.14 Exercise 39 – Configuring the Arbiters .................................................. 13120
13.15 Exercise 40 – Configuring the Interconnects.......................................... 13121
13.16 Finalizing the OpenBus Portion of the Design........................................ 13121
13.17 Exercise 41 – Configuring the Processor Memory ................................. 13122
13.18 Exercise 42 Creating a sheet symbol from an OpenBus Document .... 13123
13.19 Exercise 43 – Linking an Embedded Project to an OpenBus Design...... 13124
13.20 Exercise 44 – Processing an OpenBus Design...................................... 13125
14 Review ............................................................................................................. 14126
14
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 SVideo 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 8bit digital YCbCr 4:2:2 component video through
the use of a TVP5150AM1 video decoder device from Texas Instruments.
The decoder provides a 9bit ADC, with sampling carried out in accordance with the ITUR
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:
· 8bit ITUR BT.656 interface with embedded synchronization
· 8bit 4:2:2 YCbCr, with discrete synchronization signals
By default the TVP5150AM1 is configured to output digital video in the ITUR BT.656 format
and this is the format expected by a BT656 Controller used within and FPGA design.
15
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 ITUR BT.656compliant 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 16bppformatted data from external memory, process it, and
display it on the connected TFT LCD panel. All of the control signals are generated incore,
using an integrated TFT Timing Controller unit.
1.3 A high level view of our system
It helps to have a highlevel 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 FPGAbased BT656 decoder. This will then be processed by the
TSK3000 and output to the touch screen display using an FPGAbased VGA controller.
16
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 preverified, presynthesized
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 FPGAbased 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
“onchip” and are fixed (i.e. cannot be changed). An example might be an 8051 with an on
chip High Speed USB interface. FPGAbased 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 FPGAbased
“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 realtime modifications
to a system thus not requiring the engineer to “lockin” the hardware up front.
27
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 rightclicking 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 32bit,
Wishbonecompatible, RISC processor core. Most instructions are 32bits 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 zerowait state block RAM, with true
dualport access.
28
The TSK3000A also features:
· FPGA deviceindependent implementation
· 5stage pipelined RISC processor
· 32x32 to 64bit hardware multiplier, signed and unsigned
· 32x32bit hardware divider
· 32bit singlecycle 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 Viperbased software development tool chain – C compiler/assembler/source
level debugger/profiler
· Ccode compatible with other Altium Designer 8bit and 32bit Wishbonecompliant
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 Csize 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 (32bit Processors) dialog (Figure 4) is accessible by rightclicking the
processor in the schematic and selecting Configure... or alternatively by selecting the
Configure button in the component properties dialog.
29
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 dualport 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 CCompiler.
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.
· OnChip Debug System
The TSK3000 includes an optional onchip 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 multistep debugging
o Readwrite access for internal processor registers
o Readwrite access for memory and I/O space
o Unlimited software breakpoints
The on chipdebugging 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
210
application when switching between OCD and nonOCD 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. Rightclick the TSK3000A in the schematic and select Configure U2 (TSK3000A).

This will launch the Configure (32bit Processors) dialog.
2. Set the Internal Processor Memory option to 32K Bytes (8K x 32Bit Words)
3. Set the Multiply/Divide Unit (MDU) option to Hardware MDU
4. Set the OnChip Debug System option to Include JTAGBased OnChip Debug
System
6. Set the Breakpoints on Reset option to Disable Breakpoints on Hard Reset
211
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 opensource 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 32Bit 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
312
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)
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
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.
313
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
32bit wide data port with 8bit granularity would
allow data transfers of 8 16 or 32bits. 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
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 32bit
wide data port with 8bit granularity would allow
data transfers of 8 16 or 32bits. The Select
bits allow targeting of each of the bit ranges with
0 corresponding to the lowest range and
incrementing from there.
314
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)
315
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.
316
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
417
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
16bppformatted data from external memory and display it on the TFT panel.
Designate this part U17.
4. Rightclick 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.
418
Figure 6. Placement of peripherals in schematic
419
5 Bus Interconnectivity and Arbitration
Unlike offtheshelf microprocessors which have their peripherals fixed at the time of
manufacture, FPGAbased 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
Wishbonecompliant 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
· 1ton 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 32bit 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
520
5.2 Configuring the Wishbone Interconnect component
The Wishbone Interconnect component can be configured by rightclicking 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 dropdown 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 dropdown is used to specify the address size depending on the
type of slave peripheral(s) being connected. The 32Bit(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 24Bit(Peripheral I/O).
521
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 userdefinable field and should
meaningful when listed alongside other connected
devices.
Type Used to specify the type of Wishbone Slave Device is
being connected.
522
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 “bytetoword”
management. In word addressing mode, the mapping
of the address lines are passed to the slave device’s
data bus width:
· 32bit 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 32bit load/store instructions
· 16bit 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 halfword addresses (or
addresses at every 2 bytes). Registers/address
using the LHU and SH 16bit load/store instructions
· 8bit 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
using the LBU and SB 8bit 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.
523
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. 8bit, 16bit and 32bit 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 levelsensitive
or edgetriggered – as well as its polarity.
Interrupts generated by Altium Designer
Wishbone peripheral devices have positive
polarity and are levelsensitive, 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 32bit interrupt input bus sent to the
Wishbone Master (e.g. a 32bit 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, rightclick U1 and select Configure U1
(WB_INTERCON)…
4. Referencing Figure 10, configure the following Slave Interfaces.
524
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 24Bit(Peripheral I/O).
5.4 Managing memory access
Like their traditional ‘hard’processor counterparts; systems on FPGAs require memory
resources. Whether these resources exist onchip or offchip depends on the needs of the
system and the device selected. Generally, onchip memory is faster but consumes device
resources. Offchip memory on the other hand, though generally slower, has potentially
greater storage capacity.
For our application the bulk of our memory resources will exist offchip as SRAM on the
Spartan 3 Daughtercard. The memory controllers however will exist onchip, 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
525
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
K6R4016V1DTC10
K6R4016V1DTC10
XRAM1
SAMSUNG
SAMSUNG
SRAM Controller
TSK3000
K6R4016V1DTC11
K6R4016V1DTC11
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
526
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:
RoundRobin – 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 32bit 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 rightclicking 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
527
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".
528
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 MultiMaster 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 MultiMaster's
address bus to the same width as the ADR_I line
for the peripheral. A Wishbone Interconnect must
then be used between the MultiMaster 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. 8bit,
16bit and 32bit 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 MultiMaster device is used
to connect multiple 32bit 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.
529
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
530
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 32bit wide SDR SDRAM
SRAM Controller – interfaces to 8, 16, or 32bit wide asynchronous SRAM
BRAM Controller – interfaces to 32bit wide single or dual port Block RAM
Flash Controller – interfaces to 8, 16, or 32bit wide parallel Flash memory
· Automatic sizing of ADR_I input bus, based on specified physical memory size
· Wishbonecompliant interface
6.1 Configuring the SRAM Controller
The SRAM Controller component can be configured by rightclicking 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.
631
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.
632
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 32bit 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 autoprecharge 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 32bit processor and memories on a shared bus.
633
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 commonbus
memories located on Altium's 3connector daughter boards, such as the Xilinx Spartan3
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 rightclicking 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.
634
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 commonbus SRAM on a 3connector
daughter board is provided by two 4Mbit, highspeed
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 dropdown 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 32bit
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.
635
· 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 postwrite 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 FPGAside 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.
636
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
637
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 PortPlugin.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 PortPlugin.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 PortPlugin.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.
638
Figure 20. Schematic including the required port plugin components
639
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.
640
U5 U1 U2 U3 U4
BT656 Controller Wishbone Interconnect TSK3000A 32Bit 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
K6R4016V1DTC10
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
K6R4016V1DTC10
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
K6R4016V1DTC10
SAMSUNG
K6R4016V1DTC10
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
641
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 rightclicking 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.
742
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 redone, 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 32bit 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.
743
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 rightclick in the Device Memory section of the Configure Processor Memory
dialog and remove the large, 32 Kbytes section labeled U2. We can then rightclick 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 nonvolatile).
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.
744
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. Rightclick 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.
745
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 rightclick 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.
746
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. Rightclick 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.
747
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.
848
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 bestinclass 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 rightclicking 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.
949
Code Formatting General
Code formatting Spacing
Additional Code Formatting & Highlighting options are available under Tools»Editor
Preferences…
950
Preferences General
Preferences Display
951
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.
952
9.2 The TASKING tool chain
Many longtime users of Altium Designer are familiar with its advanced schematic and PCB
capabilities and can understand how schematicbased 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 worldleading tools for embedded software
development, bringing together the advanced software design technology needed to compete
in the embedded systems marketplace. The awardwinning TASKING integrated development
environment, compiler, debugger, embedded Internet and RTOS offerings support a wide
range of DSPs and 8, 16 and 32bit 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 toplevel source documents into a
binary file that can be executed by a target processor. This is a multistep 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.
953
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 rightclicking 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 32bit processors including FPGAbased and non FPGAbased
devices. Currently Altium Designer supports the following list of hard and soft processors.
Processor Description
TSK51 The TSK51x is the core of a fast, singlechip, 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 8bit embedded controller that
executes all ASM51 instructions and is
instruction set compatible with the 80C31.
TSK80 The TSK80x is a fully functional 8bit 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, 8bit 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.
954
TSK3000 The TSK3000A is a 32bit, Wishbone
compatible, RISC processor. Most instructions
are 32bits wide and execute in a single clock
cycle. In addition to fast register access, the
TSK3000A features a userdefinable amount of
zerowait state block RAM, with true dualport
access.
The TSK3000A has been specifically designed
to simplify the development of 32bit systems
targeted for FPGA implementation and to allow
the migration of existing 8bit systems to the 32
bit domain with relative ease and lowrisk. 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 Wishbonecompatible RISC processor, for
use in FPGA designs targeting supported Actel
Fusion or ProASIC®3 families of physical FPGA
devices.
Although placed in an Altium Designerbased
FPGA project as a CoreMP7, this is essentially a
Wishbonecompliant wrapper that allows use of
Actel's corresponding 'soft' CoreMP7 processor
core.
Similar to (and fully compatible with) the
ARM7TDMIS™ core processor, the CoreMP7 is
an implementation of the ARM® architecture
v4T. This RISC architecture supports both the
32bit ARM instruction set, as well as the 16bit
Thumb instruction set.
Altera – NIOS II The Altera® Nios® II is a fully functional, 32bit
load/store, Wishbonecompliant 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 Designerbased FPGA project as a
Nios II, this is essentially a Wishbonecompliant
wrapper that allows use of Altera's
corresponding 'soft' Nios II processor core.
All instructions are 32bits 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 userdefinable amount of
zerowait state block RAM, with true dualport
access.
The Nios II core must be licensed from Altera –
and must be purchased separately.
955
AMCC – PPC405CR Altium Designer's PPC405CR component is a
32bit Wishbonecompatible RISC processor.
FPGA project just like any other 32bit processor
component, the PPC405CR is essentially a
Wishbonecompliant 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 32bits wide and execute in
a single clock cycle. In addition to fast register
access, the PPC405CR features a user
definable amount of zerowait state block RAM,
with true dualport access.
NXP LPC2100 The NXP LPCxxx family of Microprocessors are
32bit ARMbased 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
harddevices 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 32bit Wishbonecompatible
RISC processor.
FPGA project just like any other 32bit processor
component, the ARM720T_LH79520 is
essentially a Wishbonecompliant 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 32bit SystemonChip (SoC),
based on an ARM720T 32bit 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.
956
Xilinx Microblaze The Xilinx® MicroBlaze™ is a fully functional,
32bit load/store, Wishbonecompliant 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.
FPGA project as a MicroBlaze, this is essentially
a Wishbonecompliant wrapper that allows use
of the 'soft' MicroBlaze processor core.
All instructions are 32bits wide and most
execute in a single clock cycle. In addition to fast
register access, the MicroBlaze features a user
definable amount of zerowait state block RAM,
with true dualport 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, 32bit
load/store, Wishbonecompliant processor that
employs RISC architecture with a streamlined
set of single word instructions.
As the PPC405 is immersed in a VirtexII 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 32bit system hardware platform,
use the available TSK3000A 32bit RISC
processor.
FPGA project as a PPC405A, this is essentially a
Wishbonecompliant wrapper that allows use of
the 'hard' PowerPC® (PPC405) processor core
immersed in the target physical device.
Most instructions are 32bits wide and execute in
a single clock cycle. In addition to fast register
access, the PPC405A features a userdefinable
amount of zerowait state block RAM, with true
dualport access.
957
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 processorspecific 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 preinitialized 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 highlevel 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. Highlevel Optimization
3. Instruction selection
4. Peephole Optimization / Instruction Scheduling
5. Register Allocation
6. Lowlevel Optimization
958
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
buildrelated 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 tradeoff 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 tradeoff 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.
959
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 debugability 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
floatingpoint 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
doubleprecision.
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 safetyrelated systems, along with other
960
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 handwritten or compilergenerated assembly language programs
into machine language, using the IEEE695 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.
961
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.
962
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 lowlevel 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 32bit 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.
963
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.
964
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 MinimalReal Time kernel,
supporting the POSIX.13 PSE51 RealTime 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
965
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.
966
9.6.1 Linking the projects
Linkage between projects is created
and broken using draganddrop. By
clickandholding the left mouse
button on a subproject, all possible
drop locations (valid linkage points)
will highlight in blue and the sub
project can be draganddropped 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
967
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).
968
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.
969
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 rightmost 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 realtime.
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.
970
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, insystem.
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
1071
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. Rightclick 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.
1072
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 lowlevel 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.
1073
10.4 Utilizing the Virtual Instruments
To achieve an understanding of how our design might function in its final implementation – i.e. the
“realworld,” 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 realtime.
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, insystem, 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 realtime. 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
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
1074
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. Doubleclick the Configurable Wishbone Port I/O component U14 and hit the Configure
button in the Component Properties dialog or rightclick 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 doubleclick the Wishbone Interconnect
component U1 and hit the Configure button in the Component Properties dialog or
rightclick 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.
1075
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.
LEDs[7..0] Rotation[7..0]
InLEDs[7..0] Rot[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
1076
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
1077
10.8 Exercise 20 Rebuilding the project with instruments
2. Select View >> Devices View or click on the Devices View icon in the toolbar.
middle region.
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.
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.
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.
1078
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.
1079
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 rightmost 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.
1080
11 Realtime 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 realtime. 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 OnChip Debugging
Each of the microprocessor / microcontroller cores supplied with Altium Designer include
support for On Chip Debugging (OCD). The 8bit microcontrollers will utilize a separate
schematic symbol with an ‘_D’ appended to the schematic symbol name to distinguish the
OCD and nonOCD versions of the component. Whereas the 32bit 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
nonOCD 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 rightclick 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:
1181
…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+(ba)).
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 sourcedisassembly 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 sourcedisassembly view).
1182
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
1183
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.
1184
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 ‘offloaded’ 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 Cto
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 stepdebug 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.
Doubleclicking 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
1185
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 rightclicking on an identifier
in the source code (variable, function or procedure) and choosing the Show Cross
References command from the subsequent popup menu that appears.
Note: Cross referencing must be set up for the source code documents for this feature to be
available. Enable Create CrossReference 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 crossreferencing.
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 commandline 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.
1186
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 commandline entries that correspond to common
debugging commands available from the Debug menu or toolbar:
Panel Commandline 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 highlevel source code document (*.C) currently being debugged.
Use the field at the topleft 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 stepdebug 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
1187
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 onthefly as
you debug.
As you stepdebug 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 onthefly
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. 8bit, 16bit, 32bit)
· 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.
00011110)
· 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 noneditable. The number format fields allow for
changing of register values as you debug.
1188
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 singlestep 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 sourcecode 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.
1189
Figure 59. Instrument rack for soft devices
This instrument rack is accessed by rightclicking 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:
1190
· 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 readonly, 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 rightclick 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).
1191
12 C to Hardware
In this section we will introduce you to the C to Hardware capability found in Altium Designer.
The CtoHardware 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 CtoHardware Compiler accepts standard untimed ISOC 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 CtoHardware 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 CtoHardware 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 CtoHardware Compiler?
Virtually all C programs (or functions) can be converted to an electronic circuit by the Cto
Hardware Compiler. However, the characteristics of the program determine whether the Cto
Hardware Compiler can create an efficient hardware component or whether it is better to
execute the program on a processor core. The CtoHardware 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 highend DSP and RISC processor cores.
So the main benefit of the CtoHardware 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 timeconsuming 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 CtoHardware Compiler is actually a complete toolset, including a compiler, assembler
and linker, conceptually very similar to a regular C toolset.
1292
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 ASPcomponent 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 softcore 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
1293
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 CtoHardware Compiler.
Wired into an FPGA design just like any other peripheral, the WB_ASP enables a host
processor access and control over hardwarecompiled 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
1294
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 rightclicking 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:
1295
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
1296
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.
1297
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.
1298
Figure 65. Updating the multimaster U12
7. Wire the two components as they appear in Figure 66 and Figure 67.
8. Save your work.
1299
Figure 66. Updated wiring for wishbone multimaster U3
Figure 67. Updated wiring for wishbone multimaster U3
12100
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.
12101
Option Description
Generate ASP This option provides the ability to enable or
disable generation of hardwarecompiled
functions. With this option enabled, the Cto
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 softwarebased 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 multiselect features,
allowing you to quickly select multiple variables.
Once selected, use the available rightclick
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
softwarebased function running on the host
processor.
12102
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 multiselect features,
allowing you to quickly select multiple functions.
Once selected, use the available rightclick
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.
12103
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.
5. Select View >> Devices View or click on the Devices View icon in the toolbar.
middle region.
selected.
12104
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.
12105
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 processorperipheral 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 bottomright of the main design
window. These resources provide a raised abstraction level for creating your processorbased
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 toplevel schematic as all
interface circuitry remains on the topsheet. 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
panel and select Add New to Project»Schematic
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.
13106
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.
13107
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. Singleclick the component text TSK3000A_1 and hit F2 to perform an InPlace 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
13108
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. Singleclick the component text BT656_1 and hit F2 to perform an InPlace 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. Singleclick the component text WB_ASP and hit F2 to perform an InPlace 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 32Bit TFT Controller component in
the Peripherals section. Select this component and place it into the OpenBus
document.
14. Singleclick the component text VGA32_TFT_1 and hit F2 to perform an InPlace edit of
the text. Change this to TFT.
15.
13109
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. Singleclick the component text I2CM_W_1 and hit F2 to perform an InPlace 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. Singleclick the component text WB_PRTIO_2 and hit F2 to perform an InPlace edit of
the text. Change this to GPIO.
22. Finally, reposition the OpenBus components in the schematic as they appear in the
following Figure.
13110
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. Singleclick the component text WB_INTERCON_1 and hit F2 to perform an InPlace
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.
13111
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
rightclick 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.
13112
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 toplevel 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
13113
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 crosshair.
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
13114
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 (32bit Processors) dialog as
they appear in Figure 79.
Figure 79. Configuring the processor
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
13115
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.
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
4. Save your work.
13116
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 schematicbased
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.
0
MULTIMASTER_1
XRAM1
2
1
I_MCU
2
XRAM2
1
I_ASP
MULTIMASTER_2
0
Figure 82. Placing the memory and memory interconnects / arbiters
13117
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
0
MULTIMASTER_1 XRAM1
2
1
MCU I_MCU
MEM
IO
ASP
2
XRAM2
1
TFT I_ASP
MULTIMASTER_2
0
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.
13118
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
7. Save your work.
13119
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
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
13120
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 autodefined by a hardware.h file. We had selected this option
rather than rely on the errorprone 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.
13121
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 autogenerated 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.
13122
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.
13123
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.
13124
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 schematiconly 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 schematiconly 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.
13125
14 Review
14126
FPGA to PCB
Training Module
Document Version 1.2, February 2008
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, PCAD, 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. HPGL 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...................................................................... 32
1.1 Understanding the document stack............................................................. 32
1.2 Using the FPGA to PCB project wizard ....................................................... 34
1.3 Choosing the FPGA configuration............................................................... 34
1.4 Initial FPGA pin assignments...................................................................... 35
1.5 Choosing the target PCB project................................................................. 37
1.6 Configuring the FPGA component schematic sheet .................................... 37
1.7 Configuring the sheet symbol schematic sheet ........................................... 38
1.8 Exercise 1 – Running the FPGA to PCB project wizard............................... 39
1.9 Modifying the auto generated sheet .......................................................... 311
1.10 A word about special function FPGA pins ................................................. 311
1.11 Recreating the autogenerated sheet ......................................................... 312
2. Maintaining project synchronization ................................................................. 313
2.1 The FPGA workspace map....................................................................... 313
2.2 The synchronize dialog............................................................................. 314
2.3 Synchronizing matched signals................................................................. 316
2.4 Synchronizing unmatched signals............................................................. 317
3. Configuring FPGA I/O ......................................................................................... 320
3.1 Configuring I/O standards......................................................................... 320
3.2 Exercise 2 – Using the FPGA signal manager........................................... 321
4. Manually linking FPGA and PCB projects ......................................................... 323
4.1 Supported devices.................................................................................... 324
4.2 Creating the link ....................................................................................... 324
4.3 Linking an auto generated sheet to an existing PCB project ...................... 327
4.4 Exercise 3 – Manually linking a PCB and FPGA project ............................ 327
5. Pin swapping ...................................................................................................... 328
5.1 Pin swapping in the PCB document .......................................................... 328
5.2 Pin swapping in the FPGA project............................................................. 335
5.3 Pin swapping in both PCB and FPGA projects .......................................... 336
5.4 Exercise 4 – Pin swapping........................................................................ 336
6. Commissioning the design ................................................................................ 338
6.1 Exercise 5 – Migration stage 1.................................................................. 338
6.2 Exercise 6 – Migration stage 2.................................................................. 339
6.3 Exercise 7 – Calibration............................................................................ 339
6.4 Exercise 8 – Bootstrapping the FPGA....................................................... 340
6.5 Exercise 9 – Reverting to test mode ......................................................... 341
7. Review................................................................................................................. 342
i
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 toplevel 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
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
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. Wizardbased 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
vendordevice families.
3 4
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
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
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 autogenerated 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 autogenerated 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, autogenerated schematic sheet, referred to as the 'Main Sheet'
in the Wizard.
Figure 2. The autogenerated 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
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 toplevel 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 autogenerated schematic sheet.
3 8
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_XC2S300E6PQ208.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
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 autogenerated 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. Rightclick on the PCB project in the projects panel and compile the
design. The design compiler will automatically change the project structure.
3 10
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 autogenerated 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
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
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 uptodate 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 ataglance
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
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 netrelated 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 schematicFPGA 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 unsynchronized (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
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
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 autogenerated 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
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
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 ToDo item that, once exported, will appear as follows:
Figure 17. Creating an 'Add Net' ToDo item
2.4.2 Remove ports
The Remove Ports button will remove the selected item from the Unmatched FPGA Signals box
and place a ToDo item that, once exported, will appear as follows:
Figure 18. Creating a 'Remove Port' ToDo 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 ToDo item that, once exported, will appear as follows:
Figure 19. Creating an 'Add Port' ToDo item
2.4.4 Remove nets
The Remove Nets button will remove the selected item from the Unmatched PCB Signals box and
place a ToDo item that, once exported, will appear as follows:
Figure 20. Creating a 'Remove Net' ToDo 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 ToDo item that, once exported, will appear as follows:
3 18
Figure 21. Creating a 'Rename PCB Net' ToDo 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 ToDo item that, once exported, will appear as follows:
Figure 22. Creating a 'Rename FPGA Port' ToDo item
Once ToDo 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 reestablished.
3 19
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 coexist 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 voltagereferenced 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
FPGA signals can be rapidly updated in groups by using the standard shift/ctrlselect 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 pinspecific 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
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
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
the lack of connecting lines between the SL1 Xilinx SpartanIIE 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 subprojects 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
draganddrop. 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 draganddrop.
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.
Doubleclicking 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
· Rightclicking on the entry for the FPGA component in the PCB project and choosing the Set
Sub Project command from the popup menu that appears. This will open the Select Sub
Project dialog, from where you can browse to and open the desired FPGA subproject. This
method is particularly useful if the desired subproject is not currently open in the Projects panel.
Figure 27. Linking two projects via draganddrop 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 noentry 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 subdesign of the schematic FPGA
component.
3 25
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
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 subsheets. In this case you may simply
wish to connect an existing sheet symbol to the autogenerated 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 autogenerated 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
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 porttophysical 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
backannotated 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 NetLabels 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
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 doubleclick the component in the list to access the Configure Pin Swapping For
… dialog.
3 29
Setting swap groups in the PCB
· Rightclick 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
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 twostage
process: the first stage is a fast singlepass 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
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 finetuning 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 finetune a couple of out of place nets/pins.
If any FPGA components in the design are linked, due to the design being multichannel 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
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
schematicFPGA project link appears out of date.
Figure 38. Resynchronizing 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
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 resynchronized, 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
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 schematicFPGA 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 PCBschematic 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
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
schematicFPGA 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
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
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 10pin ribbon cable, connect HDR1 on the target board to USER BOARD A on the
NanoBoard.
5. Using a 20pin ribbon cable, connect HDR2 on the target board to USER HEADER A on the
NanoBoard.
6. Ensure the Xaxis 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
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 20pin ribbon cable but leave the 10pin 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
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 standalone 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 selfcontained 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
Rightclick 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 10pin USER BOARD ribbon cable from the target board.
9. Remove the CONFIG jumper from the target board but make sure the Xaxis 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 10pin 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
7. Review
3 42

Altium FPGA To PCB

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Altium FPGA To PCB

Încărcat de

Drepturi de autor:

Formate disponibile

Unified Electronic Product Development

Altium Designer FPGA, Software and Systems Development training

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

PRJPCB PCB Project Output is a single PCB

PRJFPG FPGA Project Output is a single FPGA

Component Library Name in Library

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

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

U1 FPGA Generic.IntLib CB8CEB

U2 FPGA Generic.IntLib INV

U3 FPGA Generic.IntLib COMPM8B

DUT Design Under Test (DUT) DUT

TVP5150AM1 BT656 Controller TSK3000 VGA TFT Controller

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

Component Library Name In Library Ref Des

m1_STB_I STB_O m0_STB_I STB_O Figure 12. Wishbone

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

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

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

WBM_CYC_O MDU : Installed VIDEO_CYC_I SRAM1_LB SRAM1_LB

SDATA_EN STB_I s1_STB_O Wishbone Interconnect

DAU_TFT_STH TFT_STH io_WE_I s3_WE_O MEM_FLASH_RESET BUS_FLASH_NRESET VCC

JTAG_NEXUS_TDI TDI JTAG

JTAG_NEXUS_TMS TMS JTAG

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

Panel Command­line Corresponding Debug Command Corresponding entry

Figure 68. Configuring the wishbone ASP

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

IO MEM IO MEM

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

S-ar putea să vă placă și

8.6 IOB_x....................................................................................................... 128

SW[7..0] FPGA NB2DSK01 PortPlugin.IntLib DIPSWITCH

LEDS[7..0] FPGA NB2DSK01 PortPlugin.IntLib LED

1. Rightclick the TSK3000A in the schematic and select Configure U2 (TSK3000A).

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

1. Rightclick U2 and select Configure Processor Memory… to launch the Configure

Panel Commandline Corresponding Debug Command Corresponding entry