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

ii

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


i

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


ii

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


1 1

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

.

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

FPGA Core Components

Digital Simulation

Advanced Topics (Time Permitting)

FPGA design built and

loaded onto NanoBoard

FPGA Project Creation

FPGA Instruments

NanoBoard Concepts

FPGA Build Process

FPGA Schematic Extensions

Core Topics


1 2

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 3

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. 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.

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.

PRJPCB

PRJFPG

PRJEMB

PCB Project

FPGA Project

Embedded Project

Output is a single PCB

Output is a single FPGA

Source code for a program that will execute on a single softcore

Figure 3. An example of project hierarchy.


1 4

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 5

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 6

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. Buses can play an important role in managing these nets, and help present the design in a more readable form. Buses can be reordered, renamed, split, and merged. To manage the mapping of nets in buses, there is a special class of component, known as a bus joiner. Bus joiners can be placed from the FPGA Generic.IntLib library (bus joiner names all start with the 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.

KEY[3..0]

VALIDKEY LCD_BUSY

GND

O[7..0] IA[3..0]

IB[3..0] U8

J4B2_8B

GND

I1 I0

I2 I3 I4 I5 I6 I7

O[7..0] U9

J8S_8B

PORTB[7..0]

PORTA[7..0]

Figure 8. Examples of using bus joiners


1 7

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

The JBtype bus joiner allows you to match nets in buses of different 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

Figure 9. Bus joiners merge and split buses


1 8

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 9

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 • 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

Figure 15. The libraries panel


1 10

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 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.

Figure 16. Using wildcards to quickly find a specific component in the Generic Library


1 11

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:

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.

Component Library Name in Library

CLK_BRD FPGA NB2DSK01 PortPlugin.IntLib CLOCK_BOARD

TEST_BUTTON FPGA NB2DSK01 PortPlugin.IntLib TEST_BUTTON

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

ON FPGA NB2DSK01 PortPlugin.IntLib DIPSWITCH

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

CLR

CEO TC

CEC

Q[7..0]

U1 CB8CEB FPGA Generic.IntLib CB8CEB

U2

INV

FPGA Generic.IntLib INV

A[7..0] B[7..0]

GT LT

U3

COMPM8B

FPGA Generic.IntLib COMPM8B

I1 I0

I2 I3 I4 I5 I6 I7

O[7..0] U4

J8S_8B

FPGA Generic.IntLib J8S_8B


1 12

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

CLK_BRD

TEST_BUTTON

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

ON

LEDS[7..0]

CLR

CEO TC

CEC

Q[7..0]

U1 CB8CEB

U2

INV

A[7..0] B[7..0]

GT LT

U3

COMPM8B

I1 I0

I2 I3 I4 I5 I6 I7

O[7..0] U4

J8S_8B

VCC

GND


1 13

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 14

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 15

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 16

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 Constraintmenu.

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 17

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 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.

Figure 26. Configuring the FPGA Project Automatically


1 18

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 19

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 20

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 21

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 22

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 Toolsmenu.

• 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 23

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 24

7.6.4 Program

Figure 37. Program FPGA stage of the process flow.

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 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.

Figure 38. Successful programming of the physical FPGA device.

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 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 25

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 26

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 27

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 button can choose a number of predefined frequencies, or a custom frequency can be selected using the Other Frequency button. If the specified frequency cannot be generated the closest possible is generated and the error shown on the 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 switching instrument which provides an efficient means by which to switch signals in a design. The interconnection between input and output blocks is completely configurable. Initial connections can be defined as part of designtime configuration, but can be changed onthe fly at runtime, from the device's associated instrument panel. 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

The frequency counter is a dual input counter that can display the measured signal in 3 different modes; as a frequency, period, or number of pulses.

Frequency Generator

TIMEBASE FREQ

U7

CLKGEN

Frequency Counter

FREQA FREQB

TIMEBASE

U6

FRQCNT2

Crosspoint Switch AIN_A[7..0] AIN_B[7..0]

BIN_A[7..0] BIN_B[7..0]

AOUT_A[7..0] AOUT_B[7..0]

BOUT_A[7..0] BOUT_B[7..0]

U18

CROSSPOINT_SWITCH


1 28

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 used for both monitoring and activating nodes in the circuit. Unlike its legacy counterparts (IOB_x family of devices), with the DIGITAL_IO device you are not constrained to limited signals of 8 or 16bits. Instead, any number of signals may be added, and 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.

Configurable Digital IO InLEDs[7..0] SpareOutB[7..0] SpareOutC[7..0] SpareOutD[7..0]

Rot[7..0] Zoom[7..0] Flags[7..0]


1 29

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 30

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 31

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 directly in its associated instrument panel and send it directly to the processor in your design, to be handled by the embedded software code running therein. Conversely, it allows the display of text sent from that processor. Although classed as one of Altium Designer's virtual instruments, the TERMINAL device is really a hybrid – part instrument and part Wishbonecompliant slave peripheral. Whereas other instruments are configured and operated directly from a GUI, the TERMINAL device requires interaction at the code level, to initialize internal registers and to write to/read from its internal storage buffers.

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.

TEST_BUTTON

LEDS[7..0]

CLR

CEO TC

CEC

Q[7..0]

U1 CB8CEB

U2

INV

A[7..0] B[7..0]

GT LT

U3

COMPM8B

I1 I0

I2 I3 I4 I5 I6 I7

O[7..0] U4

J8S_8B

VCC

GND

CLK_BRD CLK_BRD

CLK_BRD

Frequency Generator

TIMEBASE FREQ

U7

CLKGEN CLK_TICK

Logic Analyser

CLK CLK_CAP CHANNELS[15..0]

TRIGGER

STATUS

U5

LAX_1K16

CLK_BRD CLK_TICK

O[15..0] IA[7..0]

IB[7..0] U6

J8B2_16B

Frequency Counter

FREQA FREQB

TIMEBASE

U9

FRQCNT2

CLK_BRD

CLK_TICK

TCK TMS

TDI TDO

TRST

JTAG

.

JTAG

JTAG

JTAG

JTAG

JTAG

. . VCC

JTAG_NEXUS_TMS JTAG_NEXUS_TCK JTAG_NEXUS_TDO JTAG_NEXUS_TDI

1 Ch x 8 Bit Digital IO

AIN[7..0] AOUT[7..0]

U8

IOB_1X8

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.

CLK_I RST_I

DAT_I[7..0] DAT_O[7..0] ADR_I[3..0]

CYC_I STB_I

WE_I

ACK_O

INT_O[1..0]

Terminal Console U1

TERMINAL


1 32

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 33

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 34

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 35

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 36

TCK TMS

TDI TDO

TRST

JTAG

.

JTAG

JTAG

JTAG

JTAG

JTAG . .

NEXUS_JTAG_PORT

VCC

JTAG_NEXUS_TMS JTAG_NEXUS_TCK JTAG_NEXUS_TDO JTAG_NEXUS_TDI

NEXUS_JTAG_CONNECTOR

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 37

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.

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

NanoTalk Chain

JTAG Hard Chain

JTAG Soft Chain


1 38

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

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

J JT TA AG G C Ce el ll l P Pa ar ra al ll le el l

D Da at ta a F Fl lo ow w

T TD DI I

T TD DO O


1 39

• 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 40

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.

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.

CLK_BRD P182 P182

http://www.icst.com/products/pdf/ics3070102.pdf

http://www.icst.com/products/ics307inputForm.html


1 41

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 42

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 43

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 44

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 45

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 46

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 47

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 48

• 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 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.

Figure 84. Specifying an FPGA project’s top level document.


1 49

Figure 85. Files generated after synthesizing the design

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

10.9 Publish Now we can publish the core project. This will zip together (archive) all the EDIF files in the core project’s Project Outputs folder and then copy this to the user EDIF models folder that was specified earlier. • Select Design » Publish. If the error message

“cannot find ‘working folder’” appears, make sure you have set up the Use presynthesized 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 50

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 51

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 52

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.

CLK_BRD

SW[7..0]

TEST_BUTTON

LEDS[7..0]

U1

MyPWMCore

CLK_BRD

TEST_BUTTON

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

ON

LEDS[7..0]

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


1 53

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.

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

VHDL Testbench

Design Under Test (DUT) DUT Inputs

DUT Outputs


1 54

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 55

Figure 9519. Specifying signals to display in the simulation.

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 display.

• 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 56

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 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.

Figure 97. The simulator menu


1 57

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


1 58

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 59

12 Review

11

Designing Systems on FPGAs

12

Document Version 1.2, April 2008

Software, documentation and related materials: Copyright © 2008 Altium Limited. All rights reserved. You are permitted to print this document provided that (1) the use of such is for personal use only and will not be copied or posted on any network computer or broadcast in any media, and (2) no modification of the document is made. Unauthorized duplication, in whole or part, of this document by any means, mechanical or electronic, including translation into another language, except for brief excerpts in published reviews, is prohibited without the express written permission of Altium Limited. Unauthorized duplication of this work may also be prohibited by local statute. Violators may be subject to both criminal and civil penalties, including fines and/or imprisonment. Altium, Altium Designer, Board Insight, CAMtastic, CircuitStudio, Design Explorer, DXP, LiveDesign, NanoBoard, NanoTalk, Nexar, nVisage, 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

13

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

14

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

15

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.

16

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.

TVP5150AM1

Analog Video Input

BT656 Controller VGA TFT Controller

ADC

TSK3000

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.

27

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.

28

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.

29

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.

210

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

211

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

312

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.

INT_I[31..0]

IO_CYC_O

IO_CLK_O

IO_ADR_O[23..0]

IO_STB_O

ME_DAT_O[31..0] ME_SEL_O[3..0]

ME_STB_O

IO_WE_O

IO_DAT_O[31..0]

ME_WE_O IO_SEL_O[3..0]

ME_ADR_O[31..0] ME_DAT_I[31..0]

IO_ACK_I ME_CYC_O ME_ACK_I

IO_DAT_I[31..0]

IO_RST_O ME_CLK_O ME_RST_O

MDU : Installed Debug Hardware : Installed Internal Memory : 32 KB

TSK3000A 32Bit RISC Processor

Current Configuration

RST_I CLK_I

TSK3000A

BT656 Controller WBS_STB_I WBS_CYC_I 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

VID_DATA[7..0] PCLK VBLK

BT656

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

http://www.opencores.org/

313

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.

http://www.opencores.org/

314

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.

315

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)

316

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.

417

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

BT656 Controller

WBS_STB_I WBS_CYC_I 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

VID_DATA[7..0] PCLK VBLK

U5

BT656

FPGA Peripherals.IntLib BT656 U5

I2C Master Wishbone

STB_I CYC_I ACK_O

ADR_I[2..0] DAT_O[7..0] DAT_I[7..0]

WE_I CLK_I RST_I INT_O

SDATA_EN

SDATAO

SDATAI

SCLK_EN

SCLKO

SCLKI

U7

I2CM_W

FPGA Peripherals.IntLib I2CM_W U7

Wishbone Display Driver

io_STB_I io_CYC_I io_ACK_O

io_ADR_I[11..0] io_DAT_O[31..0] io_DAT_I[31..0] io_SEL_I[3..0]

io_WE_I io_CLK_I io_RST_I

TFT_RED[4..0] TFT_GREEN[5..0] TFT_BLUE[4..0] TFT_CL[3..1] TFT_DISP_ON TFT_M TFT_POL TFT_STH TFT_STV

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

U17

WB_VGA

FPGA Peripherals.IntLib WB_VGA U17

418

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.

Component Library Name In Library Ref Des

U9

U10

FPGA Generic.IntLib IOBUF U9, U10

Port Wishbone

CYC_I ACK_O

STB_I

DAT_I[7..0]

WE_I CLK_I RST_I

PAO[7..0]

U14

WB_PRTIO

FPGA Peripherals.IntLib WB_PRTIO U14

419

Figure 6. Placement of peripherals in schematic

520

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

Wishbone Interconnect

s0_STB_O s0_CYC_O s0_ACK_I

s0_ADR_O[19..0] s0_DAT_I[31..0] s0_DAT_O[31..0] s0_SEL_O[3..0]

s0_WE_O s0_CLK_O 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

m0_STB_I m0_CYC_I m0_ACK_O m0_ADR_I[31..0] m0_DAT_O[31..0] m0_DAT_I[31..0] m0_SEL_I[3..0] m0_WE_I m0_CLK_I m0_RST_I

WB_INTERCON

Figure 7. Wishbone Interconnect Component

521

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).

522

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.

523


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 locations in such devices can be read and written 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 locations in such devices can be read and written 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.

524


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.

525

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

526

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

SAMSU

NG

K6R

4016

V1D

TC10

SAMSU

NG

K6R

4016

V1D

TC10

SRAM Controller

SAMSU

NG

K6R

4016

V1D

TC11

SAMSU

NG

K6R

4016

V1D

TC11

TSK3000

SRAM Controller

VGA TFT Controller

XRAM1

XRAM2

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

STB_O CYC_O ACK_I

ADR_O[31..0] DAT_I[31..0] DAT_O[31..0] SEL_O[3..0]

WE_O CLK_O RST_O



No Delay

WB_MULTIMASTER

Wishbone Dual Master

STB_O CYC_O ACK_I

ADR_O[31..0] DAT_I[31..0] DAT_O[31..0] SEL_O[3..0]

WE_O CLK_O RST_O



WB_DUALMASTER

Figure 12. Wishbone dual and multi master components

527

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

528

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".

529

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.

530

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

631

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.

SEL_I[3..0] WE_I

DAT_O[31..0] DAT_I[31..0]

ADR_I[19..0] ACK_O

STB_I CYC_I

RST_I CLK_I

SRAM Controller

SRAM0_D[15..0] SRAM0_A[17..0]

SRAM0_CE SRAM0_WE SRAM0_OE SRAM0_UB SRAM0_LB

SRAM1_D[15..0] 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.

632

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.

633

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.

634

Shared Memory Controller

SRAM_STB_I SRAM_CYC_I SRAM_ACK_O SRAM_ADR_I[19..0] SRAM_DAT_O[31..0] SRAM_DAT_I[31..0] SRAM_SEL_I[3..0] SRAM_WE_I SRAM_CLK_I SRAM_RST_I

MEM_D[31..0] MEM_A[23..0]

MEM_W MEM_OE

MEM_BE[3..0] MEM_SDRAM_CKE MEM_SDRAM_RAS MEM_SDRAM_CAS

MEM_SDRAM_E 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.

635

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.

636

• 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.

637

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

638

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.

639

Figure 20. Schematic including the required port plugin components

640

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.

641

INT_I[31..0]

IO_C

YC_O

IO_C

LK_O

IO_A

DR_O

[23..0]

IO_STB

_O

ME_DAT_O[31..0]

ME_SEL_O[3..0]

ME_STB_O

IO_W

E_O

IO_D

AT_O[31..0]

ME_WE_O

IO_SEL_O

[3..0]

ME_ADR_O

[31..0]

ME_DAT_I[31..0]

IO_A

CK_I

ME_CYC_O

ME_ACK_I

IO_D

AT_I[31..0]

IO_R

ST_O

ME_CLK_O

ME_RST_O

MDU : Installed

Debug Hardware : Installed

Internal Memory : 32 KB

TSK3000A 32Bit RISC Processor

Current Configuration

RST_I

CLK_I

U2

TSK3000A


STB_O

CYC_O

ACK_I

ADR_O[19..0]

DAT_I[31..0]

DAT_O[31..0]

SEL_O[3..0]

WE_O

CLK_O

RST_O

MCU_STB

_I

MCU_C

YC_I

MCU_A

CK_O

MCU_A

DR_I[19..0]

MCU_D

AT_O[31..0]

MCU_D

AT_I[31..0]

MCU_SEL_I[3..0]

MCU_W

E_I

MCU_C

LK_I

MCU_R

ST_I

VIDEO

_STB

_I

VIDEO

_CYC_I

VIDEO

_ACK_O

VIDEO

_ADR_I[19..0]

VIDEO

_DAT_O[31..0]

VIDEO

_DAT_I[31..0]

VIDEO

_SEL_I[3..0]

VIDEO

_WE_I

VIDEO

_CLK_I

VIDEO

_RST_I

High Priority

No Delay

U3

WB_M

ULTIM

ASTER

SEL_I[3..0]

WE_I

DAT_O[31..0]

DAT_I[31..0]

ADR_I[19..0]

ACK_O

STB_I

CYC_I

RST_I

CLK

_I SRAM Controller

SRAM0_D[15..0]

SRAM0_A[17..0]

SRAM0_CE

SRAM0_WE

SRAM0_OE

SRAM0_UB

SRAM0_LB

SRAM1_D[15..0]

SRAM1_A[17..0]

SRAM1_CE

SRAM1_WE

SRAM1_OE

SRAM1_UB

SRAM1_LB

U4

WB_M

EM_CTR

L


s0_STB_O

s0_CYC_O

s0_A

CK_I

s0_ADR_O[19..0]

s0_DAT_I[31..0]

s0_D

AT_O[31..0]

s0_SEL_O

[3..0]

s0_W

E_O

s0_C

LK_O

s0_RST_O

s1_STB_O

s1_CYC_O

s1_A

CK_I

s1_ADR_O[19..0]

s1_DAT_I[31..0]

s1_D

AT_O[31..0]

s1_SEL_O

[3..0]

s1_W

E_O

s1_C

LK_O

s1_RST_O

m0_STB_I

m0_CYC_I

m0_ACK_O

m0_ADR_I[31..0]

m0_DAT_O[31..0]

m0_DAT_I[31..0]

m0_SEL_I[3..0]

m0_WE_I

m0_CLK

_I

m0_RST_I

U8

WB_INTERCON


s0_STB_O

s0_CYC_O

s0_ACK_I

s0_ADR_O

[2..0]

s0_DAT_I[31..0]

s0_DAT_O[31..0]

s0_SEL_O[3..0]

s0_W

E_O

s0_CLK

_O

s0_RST_O

s1_STB_O

s1_CYC_O

s1_ACK_I

s1_ADR_O

[2..0]

s1_DAT_I[7..0]

s1_DAT_O[7..0]

s1_SEL_O[3..0]

s1_W

E_O

s1_CLK

_O

s1_RST_O

s2_STB_O

s2_CYC_O

s2_ACK_I

s2_DAT_I[7..0]

s2_DAT_O[7..0]

s2_SEL_O[3..0]

s2_W

E_O

s2_CLK

_O

s2_RST_O

s3_STB_O

s3_CYC_O

s3_ACK_I

s3_ADR_O

[11..0]

s3_DAT_I[31..0]

s3_DAT_O[31..0]

s3_SEL_O[3..0]

s3_W

E_O

s3_CLK

_O

s3_RST_O

m0_STB_I

m0_CYC_I

m0_ACK_O

m0_ADR_I[23..0]

m0_DAT_O[31..0]

m0_DAT_I[31..0]

m0_SEL_I[3..0]

m0_WE_I

m0_CLK

_I

m0_RST_I

m0_INT_O[31..0]

U1

WB_INTERCON

Port Wishbone

CYC_I

ACK_O

STB_I

DAT_I[7..0]

WE_I

CLK_I

RST_I

PAO[7..0]

U14

WB_PRTIO

BT656 Controller

WBS_STB_I

WBS_CYC_I

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_C

YC_O

WBM_ACK_I

WBM_A

DR_O

[31..0]

WBM_D

AT_O[31..0]

WBM_SEL_O[3..0]

WBM_W

E_O

VID_DATA[7..0]

PCLK

VBLK

U5

BT656

I2C Master W

hishbone

STB_I

CYC_I

ACK_O

ADR_I[2..0]

DAT_O[7..0]

DAT_I[7..0]

WE_I

CLK_I

RST_I

INT_O

SDATA_EN

SDATAO

SDATAI

SCLK_EN

SCLKO

SCLKI

U7

I2CM_W

U9

U10


STB_O

CYC_O

ACK_I

ADR_O

[19..0]

DAT_I[31..0]

DAT_O[31..0]

SEL_O[3..0]

WE_O

CLK

_O

RST_O

MCU_STB

_I

MCU_C

YC_I

MCU_A

CK_O

MCU_A

DR_I[19..0]

MCU_D

AT_O[31..0]

MCU_D

AT_I[31..0]

MCU_SEL_I[3..0]

MCU_W

E_I

MCU_C

LK_I

MCU_R

ST_I

TFT_STB_I

TFT_CYC_I

TFT_ACK_O

TFT_ADR_I[19..0]

TFT_DAT_O[31..0]

TFT_DAT_I[31..0]

TFT_SEL_I[3..0]

TFT_WE_I

TFT_CLK

_I

TFT_RST_I High Priority

No Delay

U12

WB_M

ULTIMASTER

SDA

SCL

TVP5150AM1

LEDS[7..0]

DAU_TFT_M

DAU_TFT_POL

DAU_TFT_STH

DAU_TFT_STV

DAU_TFT_DISP_ON

DAU_TFT_B

LIGHT

DAU_TFT_M

UX

DAU_TFT_R

ED[4..0]

DAU_TFT_GREEN[5..0]

DAU_TFT_BLU

E[4..0]

DAU_TFT_C

L[3..1]

DAU_TFT_IRQ

SRAM0_E

SRAM0_A[17..0]

SRAM0_W

SRAM0_OE

SRAM0_UB

SAMSUNG K6R4016V1DTC10

SRAM0_D[15..0]

SRAM0_LB

SRAM1_E

SRAM1_A[17..0]

SRAM1_W

SRAM1_OE

SRAM1_UB


SRAM1_D[15..0]

SRAM1_LB

Wishbone Display Driver

io_STB_I

io_CYC_I

io_A

CK_O

io_A

DR_I[11..0]

io_D

AT_O[31..0]

io_DAT_I[31..0]

io_SEL_I[3..0]

io_W

E_I

io_C

LK_I

io_RST_I

TFT_RED

[4..0]

TFT_GREEN[5..0]

TFT_BLU

E[4..0]

TFT_CL[3..1]

TFT_DISP_ON

TFT_M

TFT_PO

L

TFT_STH

TFT_STV

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

U17

WB_VGA

VIDIN_D

ATA[7..0]

VIDIN_PCLK

VIDIN_INTERQ_GPLC

TVP5150AM1

VIDIN_A

VID

VIDIN_H

SYNC

VIDIN_V

SYNC

VIDIN_FID_C

LCO

TCK

TMS

TDI

TDO

TRST

JTAG

.

JTAG

JTAG

JTAG

JTAG

JTAG

. . JTAG_N

EXUS_TM

S JTAG_NEX

US_TC

K

JTAG_NEX

US_TD

O

JTAG_N

EXUS_TD

I

CLK_B

RD

TEST_BUTTON

U16

INV

TFT_STB

TFT_CYC

TFT_ACK

TFT_ADR[19..0]

TFT_DIN[31..0]

TFT_SEL[3..0]

TFT_WE

VID_STB

VID_CYC

VID_ACK

VID_ADR[31..0]

VID_DOUT[31..0]

VID_SEL[3..0]

VID_W

E GND

MCU_STB

MCU_CYC

MCU_ACK

MCU_ADR[31..0]

MCU_DIN[31..0]

MCU_DOUT[31..0]

MCU_SEL[3..0]

MCU_W

E

MCU_CLK

MCU_RST

VCC

VCC

CLK

RST

MCU1_STB

MCU1_CYC

MCU1_ACK

MCU1_ADR[19..0]

MCU1_DIN[31..0]

MCU1_DOUT[31..0]

MCU1_SEL[3..0]

MCU1_WE

MCU1_CLK

MCU1_RST

VID_STB

VID_C

YC

VID_A

CK

VID_A

DR[19..0]

VID_D

OUT[31..0]

VID_SEL[3..0]

VID_W

E

CLK

RST

MCU2_STB

MCU2_CYC

MCU2_ACK

MCU2_ADR[19..0]

MCU2_DIN[31..0]

MCU1_DOUT[31..0]

MCU2_SEL[3..0]

MCU2_WE

MCU2_CLK

MCU2_RST

TFT_STB

TFT_CYC

TFT_ACK

TFT_ADR[19..0]

TFT_DIN[31..0]

TFT_SEL[3..0]

TFT_WE

CLK

RST

GND MCU_STB

MCU_C

YC

MCU_A

CK

MCU_A

DR[31..0]

MCU_D

IN[31..0]

MCU_D

OUT[31..0]

MCU_SEL[3..0]

MCU_W

E

MCU_C

LK

MCU_R

ST

MCU1_STB

MCU1_CYC

MCU1_ACK

MCU1_ADR[19..0]

MCU1_DIN[31..0]

MCU1_DOUT[31..0]

MCU1_SEL[3..0]

MCU1_WE

MCU1_CLK

MCU1_RST

MCU2_STB

MCU2_CYC

MCU2_ACK

MCU2_ADR[19..0]

MCU2_DIN[31..0]

MCU2_DOUT[31..0]

MCU2_SEL[3..0]

MCU2_WE

MCU2_CLK

MCU2_RST

CLK

RST


BUS_D[31..0]

BUS_SD

RAM_C

LK

BUS_NWE

BUS_NOE

BUS_NBE[3..0]


BUS_A[24..1]

BUS_RAM_N

CS

BUS_FLASH

_NBUSY

BUS_SD

RAM_C

KE

BUS_SD

RAM_N

RAS

BUS_SD

RAM_N

CAS

BUS_SD

RAM_N

CS

BUS_FLASH

_NRESET

BUS_FLASH

_NCS

GND

VCC

VCC

X

VCC

VCC

VCC

VCC

Shared Mem

ory Controller

SRAM_STB

_I

SRAM_C

YC_I

SRAM_A

CK_O

SR

AM_A

DR_I[19..0]

SRAM_D

AT_O[31..0]

SRAM_D

AT_I[31..0]

SRAM_SEL_I[3..0]

SRAM_W

E_I

SRAM_C

LK_I

SRAM_R

ST_I

MEM

_D[31..0]

MEM

_A[23..0]

MEM

_W

MEM

_OE

MEM

_BE[3..0]

MEM

_SDRAM_C

KE

MEM

_SDRAM_R

AS

MEM

_SDRAM_C

AS

MEM

_SDRAM_E

MEM

_FLA

SH_B

USY

MEM

_FLASH

_RESET

MEM

_FLA

SH_E

MEM

_SRAM_E

U13

WB_SHARED

_MEM

_CTRL

GND

Figure 21. Completed schematic with the required wiring

742

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.

743

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.

744

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.

745

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.

746

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.

747

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.

848

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.

949

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.

950

Code Formatting General

Code formatting Spacing

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

951

Preferences General

Preferences Display

952

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.

953

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.

954

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.

955


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.

956


AMCC – PPC405CR Altium Designer's PPC405CR component is a 32bit Wishbonecompatible RISC processor. Although placed in an Altium Designerbased 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. Although placed in an Altium Designerbased 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.

http://www.nxp.com/

957


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. Although placed in an Altium Designerbased 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. Although placed in an Altium Designerbased 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.

958

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

959

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.

960

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

961

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.

962

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.

963

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.

964

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.

965

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

966

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).

In the File View, files are grouped primarily according to which project they are a part of and secondarily according to the file type – schematic, PCB, settings, etc.

Figure 38. Linked projects (Structure Editor).

In the Structure Editor, the hierarchical linkage between projects is shown – i.e. above we see that the embedded project has been linked to U3 (the TSK3000A core) in the FPGA project.

967

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

968

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).

969

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.

970

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.

1071

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

1072

The following table details the various options in the Section dialog.

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.

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.

1073

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.

1074

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 Configurable Digital IO

InLEDs[7..0] SpareOutB[7..0] SpareOutC[7..0] SpareOutD[7..0]

Rot[7..0] Zoom[7..0] Flags[7..0]

We will utilize the Configurable Digital IO component to control the rotation and scaling of our image on the TFT display.

Logic Analyzer 1k x 8

Logic Analyser 1k x 8 CLK STATUS CLK_CAP EXT_TRIGGER

Measure LEDS[7..0]

U16

LAX

We will use the Logic analyzer to monitor the signals coming out of the Wishbone Port IO component; specifically those being sent to the LEDs on the NanoBoard.

Frequency Generator

Frequency Generator

TIMEBASE FREQ

U19

CLKGEN

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

Frequency Counter

Frequency Counter

FREQA FREQB

TIMEBASE

U18

FRQCNT2

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

1075

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.

1076

10.7 Exercise 19 – Adding the Virtual Instruments 1. Go to the Libraries panel and place the component DIGTAL_IO. Designate this

component U11. 2. Right click this component and select Configure U11 (DIGITAL_IO)… Configure the

component as it appears in Figure 44.

Figure 44. Digital IO component configured for the design

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

Configurable Digital IO InLEDs[7..0] SpareOutB[7..0] SpareOutC[7..0] SpareOutD[7..0]

Rot[7..0] Zoom[7..0] Flags[7..0]

Zoom[7..0] LEDs[7..0] Rotation[7..0]

Flags[7..0] SpareOutB[7..0] SpareOutC[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.

Frequency Counter

FREQA FREQB

TIMEBASE

U18

FRQCNT2

CLK

LEDs0

Frequency Generator

TIMEBASE FREQ

U19

CLKGEN

CLK LAX_CLK

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

1077

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.

Logic Analyser 1k x 8 CLK STATUS CLK_CAP EXT_TRIGGER

Measure LEDS[7..0]

U16

LAX

CLK

LEDs[7..0]

LEDs0 LAX_CLK

Figure 47. Wiring for the configurable LAX

1078

10.8 Exercise 20 Rebuilding the project with instruments 1. Make sure your Desktop NanoBoard is connected to your PC and powered on.

2. Select View >> Devices View or click on the Devices View icon in the toolbar. 3. Ensure that the Live checkbox is checked. You should see a picture of the Desktop



5. Locate the Compile, Synthesize, Build, Program FPGA buttons running left to right just below the Desktop NanoBoard icon. Click once on the words Program FPGA to begin the build process.

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

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

1. Right click the embedded project EmbeddedProject.PrjEmb and select Add New to Project. Add a new H File.

2. Add the contents of the snippet Spinning_Video_Defines_Header to this source file.

3. Save the file as defines.h. 4. Right click the embedded project EmbeddedProject.PrjEmb and select Add New to

Project. Add a new H File. 5. Add the contents of the snippet Spinning_Video_DSF_Header to this source file. 6. Save the file as dsf.h. 7. Right click the embedded project EmbeddedProject.PrjEmb and select Add New to

Project. Add a new C File. 8. Add the contents of the snippet Spinning_Video_DSF_SourceFile to this source

file. 9. Save the file as dsf.c.

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

1. Open the main.c source file in the project EmbeddedProject.PrjEmb 2. Select and delete all of the source code located in this file. 3. Add the contents of the snippet Spinning_Video_main_SourceFile to this source

file. 4. Save the file as main.c 5. Save the embedded project EmbeddedProject.PrjEmb by right clicking the project

document in the Projects panel and selecting Save Project.

1079

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.

1080

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.

1181

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:

1182

…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).

1183

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

1184

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.

1185

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

1186

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.

1187

you issue them and the current execution point. For example, if you issue a Step Into command from the

Debugmenu 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 Debugmenu or toolbar:

Panel Commandline Entry

Corresponding Debug Command on Debug Menu

Corresponding entry in Debug toolbar

C Run

C n (where n = line number)

Run to Cursor

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 Debugmenu 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

1188

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.

1189

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.

1190

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:

1191

• 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).

1292

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.

1293

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

1294

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

1295

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:

1296

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

1297

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.

1298

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.

1299

Figure 65. Updating the multimaster U12

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

12100

Figure 66. Updated wiring for wishbone multimaster U3

Figure 67. Updated wiring for wishbone multimaster U3

12101

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.

12102

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 – Global Variables

This list reflects all global variables present in the linked embedded software project. If you want to 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.

12103

Option Description

Symbols In Hardware – Function

This list reflects all functions present in the linked embedded software project. If you want to 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.

12104

Figure 69. Configuring the wishbone ASP

What we have done is move the two functions, rotate and set_tabs into hardware. The rotate function performs the rotation of the video, and the set_tabs function builds our Sine and Cosine tables. The global variables costab and sintab have also been moved to hardware as these are used by both of these functions and can be accessed more quickly when accessed from ASP block RAM.

3. Click OK to close the dialog. 4. Make sure your Desktop NanoBoard is connected to your PC and powered on.

5. Select View >> Devices View or click on the Devices View icon in the toolbar. 6. Ensure that the Live checkbox is checked. You should see a picture of the Desktop



12105

8. Locate the Compile, Synthesize, Build, Program FPGA buttons running left to right just below the Desktop NanoBoard icon. Click once on the words Program FPGA to begin the build process.

9. Once the design has completed the build process, return to the Devices view and right click the Digital IO instrument and select Instrument.

10. From the Instrument Rack, adjust the Rot[7..0] and Zoom[7..0] sliders to see the performance improvement when utilizing C to Hardware.

13106

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 3. Right click the project FPGA project FPGA_Project1.PrjFpg in the Projects

panel and select Add New to Project»Schematic 4. Right click the project FPGA project FPGA_Project1.PrjFpg in the Projects

panel and select Save Project As… This will prompt you to first save the schematic, then the OpenBus document, and lastly the FPGA project document. Save these as Video_Capture_Schematic.SchDoc, Video_Capture_OpenBus.OpenBus, and Video_Capture.PrjFpg respectively.

5. From the Projects panel, select the OpenBus document to give it focus in the main workspace.

13107

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.

13108

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

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.

Figure 72. Repositioning the OpenBus ports on the MCU

IO MEM

TSK3000A_1

IO MEM

MCU

IO MEM

MCU

IO

MEM

MCU

13109

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.

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.

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.

BT656_1 VIDEO

BT656_1 VIDEO

13110

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:

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.

I2C I2CM_W_1

13111

TFT

VIDEO

ASP

IO

MEM

MCU

GPIO

I2C

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.

13112

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 Link(s) Shape

This command allows you to quickly normalize 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.

13113

Toolbar Item Command Description

Flip OpenBus Link(s) Shape

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

Straighten OpenBus Link(s) Shape

Allows you to quickly straighten one or more 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 Signals and Interrupts

Use this command to access the OpenBus 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.

IO

MEM

MCU I_IO

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

13114

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.

TFT

VIDEO

ASP

IO

MEM

MCU

GPIO

I2C

I_IO

Figure 78. Connecting the peripherals

13115

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

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

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

Figure 80. Configuring the Port IO

13116

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.


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


13117

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.

I_ASP

I_MCU

XRAM1

XRAM2

0

1

2

MULTIMASTER_1

0

1

2

MULTIMASTER_2

Figure 82. Placing the memory and memory interconnects / arbiters

13118

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.

TFT

VIDEO

ASP

IO

MEM

MCU

I_ASP

I_MCU

XRAM1

XRAM2

0

1

2

MULTIMASTER_1

0

1

2

MULTIMASTER_2

Figure 83. Connecting the memory side of the design

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

1. Right click XRAM1 in the OpenBus document and select Configure XRAM1 (SRAM Controller) to launch the component’s configuration dialog.

2. This dialog matches exactly the dialog we had used in schematic. In the Configure (Memory Controller) dialog, specify the settings to match the following figure.

13119

Figure 84. Configuring the Memory Controller XRAM1

3. Click OK to close the dialog and return to the OpenBus document. 4. Right click XRAM2 in the OpenBus document and select Configure XRAM2 (SRAM

Controller) to launch the component’s configuration dialog. 5. In the Configure (Memory Controller) dialog, specify the settings to match the

following figure.

Figure 85. Configuring the Memory Controller XRAM2

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

13120

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

1. Right click MULTIMASTER_1 in the OpenBus document and select Configure MULTIMASTER_1 (Arbiter) to launch the component’s configuration dialog.

2. In the Configure OpenBus Arbiter dialog, specify the settings to match the following figure.

Figure 86. Configuring the OpenBus arbiter

3. Click OK to close the dialog and return to the OpenBus document. 4. Right click MULTIMASTER_2 in the OpenBus document and select Configure

MULTIMASTER_2 (Arbiter) to launch the component’s configuration dialog. 5. In the Configure OpenBus Arbiter dialog, specify the settings to match the following

figure.

Figure 87. Configuring the OpenBus arbiter

13121

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.

13122

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.

13123

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.

13124

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.

13125

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. 8. Locate the Compile, Synthesize, Build, Program FPGA buttons running left to right

just below the Desktop NanoBoard icon. Click once on the words Program FPGA to begin the build process.

14126

14 Review

FPGA to PCB Training Module

Document Version 1.2, February 2008

Software, documentation and related materials: Copyright © 2008 Altium Limited. All rights reserved. You are permitted to print this document provided that (1) the use of such is for personal use only and will not be copied or posted on any network computer or broadcast in any media, and (2) no modification of the document is made. Unauthorized duplication, in whole or part, of this document by any means, mechanical or electronic, including translation into another language, except for brief excerpts in published reviews, is prohibited without the express written permission of Altium Limited. Unauthorized duplication of this work may also be prohibited by local statute. Violators may be subject to both criminal and civil penalties, including fines and/or imprisonment. Altium, Altium Designer, Board Insight, CAMtastic, CircuitStudio, Design Explorer, DXP, LiveDesign, NanoBoard, NanoTalk, Nexar, nVisage, 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

i

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

Altium Designer Training Module FPGA to PCB

3 2

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 3

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 mustmatch 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 4

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 5

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 6

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 7

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 8

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 bank (VREF only)

Tie all unused VREF pins to a port on a bank by bank basis (which 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 9

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 10

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 11

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 12

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 13

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 14

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 15

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 16

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 17

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 18

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 19

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 20

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 Toolsmenu, 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 21

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 22

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 23

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 24

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 25

• 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 26

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 27

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 28

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 29

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 30

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 31

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 32

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 33

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 34

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 35

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 Designmenu. 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 36

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 37

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 Designmenu, 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 38

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 39

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 40

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 41

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 42

7. Review

Documents

Altium FPGA to PCB