latticemico32 tutorial

LatticeMico32 Tutorial

Lattice Semiconductor Corporation5555 NE Moore CourtHillsboro, OR 97124(503) 268-8000

August 2007

LatticeMico32 Tutorial ii

CopyrightCopyright © 2007 Lattice Semiconductor Corporation.

This document may not, in whole or part, be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine-readable form without prior written consent from Lattice Semiconductor Corporation.

TrademarksLattice Semiconductor Corporation, L Lattice Semiconductor Corporation (logo), L (stylized), L (design), Lattice (design), LSC, E2CMOS, Extreme Performance, FlashBAK, flexiFlash, flexiMAC, flexiPCS, FreedomChip, GAL, GDX, Generic Array Logic, HDL Explorer, IPexpress, ISP, ispATE, ispClock, ispDOWNLOAD, ispGAL, ispGDS, ispGDX, ispGDXV, ispGDX2, ispGENERATOR, ispJTAG, ispLEVER, ispLeverCORE, ispLSI, ispMACH, ispPAC, ispTRACY, ispTURBO, ispVIRTUAL MACHINE, ispVM, ispXP, ispXPGA, ispXPLD, LatticeEC, LatticeECP, LatticeECP-DSP, LatticeECP2, LatticeECP2M, LatticeMico8, LatticeMico32, LatticeSC, LatticeSCM, LatticeXP, LatticeXP2, MACH, MachXO, MACO, ORCA, PAC, PAC-Designer, PAL, Performance Analyst, PURESPEED, Reveal, Silicon Forest, Speedlocked, Speed Locking, SuperBIG, SuperCOOL, SuperFAST, SuperWIDE, sysCLOCK, sysCONFIG, sysDSP, sysHSI, sysI/O, sysMEM, The Simple Machine for Complex Design, TransFR, UltraMOS, and specific product designations are either registered trademarks or trademarks of Lattice Semiconductor Corporation or its subsidiaries in the United States and/or other countries. ISP, Bringing the Best Together, and More of the Best are service marks of Lattice Semiconductor Corporation.

HyperTransport is a licensed trademark of the HyperTransport Technology Consortium in the U.S. and other jurisdictions.

Other product names used in this publication are for identification purposes only and may be trademarks of their respective companies.

LatticeMico32 Tutorial iii

Type Conventions Used in This Document

Convention Meaning or Use

Bold Items in the user interface that you select or click. Text that you type into the user interface.

<Italic> Variables in commands, code syntax, and path names.

Ctrl+L Press the two keys at the same time.

Courier Code examples. Messages, reports, and prompts from the software.

... Omitted material in a line of code.

.

.

.

Omitted lines in code and report examples.

[ ] Optional items in syntax descriptions. In bus specifications, the brackets are required.

( ) Grouped items in syntax descriptions.

{ } Repeatable items in syntax descriptions.

| A choice between items in syntax descriptions.

LatticeMico32 Tutorial iv

LatticeMico32 Tutorial v

Contents

LatticeMico32 Tutorial 1Introduction 1

Learning Objectives 2Time to Complete This Tutorial 2System Requirements 2Accessing Online Help 3About the Tutorial Design 3About the Tutorial Data Flow 3

LatticeMico32/DSP Development Board 6Task 1: Creating a New ispLEVER Project 7Task 2: Creating the Microprocessor Platform 9

Creating a New MSB Platform 9Selecting the Microprocessor Core 14Adding the Off-Chip Memory 16Adding the Peripheral Components 18Specifying the Connections Between Master and Slave Ports 20Assigning Component Addresses 22Assigning Interrupt Request Priorities 25Performing a Design Rule Check 25Generating the Microprocessor Platform 25

Task 3: Generating the Microprocessor Bitstream 29Importing the Verilog File 29Connecting the Microprocessor to the FPGA Pins 30Performing Functional Simulation 31Performing Timing Simulation 31Generating the Bitstream 31

Task 4: Downloading the Hardware Bitstream to the FPGA 32Task 5: Creating the Software Application Code 35

Creating a New C/C++ SPE Project 37Selecting Linker Memory Settings 39Compiling the Project 41

Contents

LatticeMico32 Tutorial vi

Task 6: Debugging and Executing the Software Application Code on the Development Board 45Software Application Code Execution Flow 45Debugging the Software Application Code on the Board 47Inserting Breakpoints 54Executing the Software Application Code 55Modifying and Re-Executing the Software Application Code 58

Task 7: Deploying the Software Application Code to the Parallel Flash Memory 59Parallel Flash Memory Deployment Flow 59Creating a CFI Flash Programmer Application 62Preparing LEDTest for Flash Deployment 64

Task 8: Deploying the Microprocessor Bitstream to SPI Flash Memory 71Summary 73Glossary 74Recommended References 77

LatticeMico32 Tutorial 1

LatticeMico32 Tutorial

IntroductionThis tutorial steps you through the basic process involved in using the LatticeMico32 System software to implement a soft microprocessor and attached components in a Lattice Semiconductor device for the LatticeMico32/DSP development board. LatticeMico32 System encompasses three tools: the Mico System Builder (MSB), the C/C++ Software Project Environment (C/C++ SPE), and the Debugger. Together, they enable you to build an embedded microprocessor system on a single FPGA device and to write and debug the software that drives it. Such a microprocessor lowers cost by saving board space and increases performance by reducing the number of external wires.

The LatticeMico32 System interface is based on the Eclipse environment, which is an open-source development and application framework for building software.

Although you can install LatticeMico32 System as a stand-alone tool, this tutorial assumes that you have installed ispLEVER before installing LatticeMico32 System. Once you create a project in ispLEVER, the tutorial shows you how to use MSB to choose a Lattice Semiconductor 32-bit microprocessor, attach components to it, and generate a top-level design, including the microprocessor and the chosen components. Next you will use ispLEVER to synthesize, map, place, and route the design and generate a bitstream for it. You then download this bitstream to the FPGA on the board. The tutorial continues by demonstrating how to use C/C++ SPE to write and compile the software application code that exercises the microprocessor and components. Finally, you learn how to download and debug the code on the board and deploy it in the parallel flash chips on the LatticeMico32/DSP development board.

LatticeMico32 Tutorial Introduction


This tutorial is intended for a new or infrequent user of the LatticeMico32 System software and covers only the basic aspects of it. The tutorial assumes that you have reviewed the LatticeMico32 Development Kit User’s Guide to familiarize yourself with the product and to set up your board correctly.

For more detailed information on the LatticeMico32 System software, see the sources listed in “Recommended References” on page 77.

Learning ObjectivesWhen you have completed this tutorial, you should be able to do the following:

Use MSB to configure a Lattice Semiconductor 32-bit microprocessor for your design, select the desired components, and connect the selected components to the microprocessor.

Import the Verilog file generated by MSB and an .lpf file containing the pinout.

Synthesize, map, place, and route the design.

Generate a bitstream of the microprocessor and download it to an FPGA on the board.

Use C/C++ SPE to create the software application code that drives the microprocessor and components.

Compile, download, and debug the software application code on the LatticeMico32/DSP development board.

Program the Common Flash Interface (CFI) parallel flash memory with the software application code.

Debug the hardware and software on the board.

Time to Complete This TutorialThe time to complete this tutorial is about one hour.

System RequirementsYour PC system must meet the following minimum system requirements:

Pentium II PC running at 400 MHz or faster

Microsoft Windows 2000 or Windows XP Professional

USB port for use with the LatticeMico32/DSP development board

The following software is required to complete the tutorial:

ispLEVER software with device support for the device used with your build of the LatticeMico32/DSP development board

LatticeMico32 System evaluation tool chain for LatticeMico32, version 1.0

ispVM System software, which is included in the ispLEVER software

This tutorial requires the following hardware:

A LatticeMico32/DSP development board



USB cable

AC adapter cord

Accessing Online HelpYou can access the online Help for MSB, C/C++ SPE, the Debugger, or Eclipse Workbench by choosing Help > Help Contents in the LatticeMico32 System graphical user interface.

About the Tutorial DesignThis tutorial uses a LatticeECP device. The tutorial design consists of the LatticeMico32 embedded microprocessor, a memory, a GPIO, a parallel flash memory, and a UART. After you add these components, you will specify the connections between the master and slave ports on these components, as shown in Figure 1.

The instruction port (I) and the data port (D) of the CPU are the master ports. All other ports are slave ports. The instruction port will access the LatticeMico32 asynchronous SRAM controller and the LatticeMico32 parallel flash memory. The data port will access the LatticeMico32 asynchronous SRAM controller, the LatticeMico32 GPIO, the LatticeMico32 parallel flash memory, and the LatticeMico32 UART.

About the Tutorial Data FlowYou will perform the following major steps to create an embedded microprocessor system:

1. Create a new project in the ispLEVER Project Navigator.

Figure 1: Desired Connections Between Master and Slave Ports

SRAM slave device (memory for code and data)

GPIO slave device (for controlling LEDs)

UART slave device (for host comunication)

LM32 CPU (master ports)

Data port

Instruction port

Parallel flash memory (for deploying the application code)



2. Create a microprocessor platform for the LatticeMico32 microprocessor in MSB.

3. Generate a bitstream of the microprocessor platform in ispLEVER and download it to the board with ispVM.

4. Download the hardware bitstream to the FPGA.

5. Write the software application code for the microprocessor platform in C/C++ SPE.

6. Debug and execute the software application code on the board.

7. Deploy the software application code in the parallel flash memory.

8. Deploy the microprocessor bitstream.

The design flow involved in using LatticeMico32 System to create an embedded microprocessor and the software code for it is shown in Figure 2.

Note

This tutorial does not show you how to debug your software application code on the instruction set simulator, but it does show you how to debug the design by downloading the bitstream and the application code to the board.



Figure 2: LatticeMico32 System Design Flow

Create microprocessor platform with MSB

Create application code with C/C++ SPE

System definition (header) file

Linkerscript

Configura-tion (.msb) file

Perform functional simulation in ispLEVER (optional)

Download bitstream to board with ispVM

.elf file

Run/debug hardware and software on board

.bit file

ispTRACY (for hardware) JTAG port

or UART

Improve hardware and software

Run/debug software with instruction set simulator (ISS) (optional)

C/C++ SPE Debugger (for software)

SPE Debugger (for software)

Test fixture (.v) file

Download .elf file to parallel flash memory or PROM

Synthesize, map, place, and route in ispLEVER

Generate bitstream in ispLEVER

Perform timing simulation in ispLEVER (optional)

MSB C/C++ SPE

ispLEVER

Top-level simulation & synthesis RTL (.v) files

LatticeMico32 Tutorial LatticeMico32/DSP Development Board


LatticeMico32/DSP Development BoardFigure 3 shows where some of the components mentioned in this tutorial reside on the LatticeMico32/DSP development board.

Figure 3: The LatticeMico32/DSP Development Board

LatticeMico32 Tutorial Task 1: Creating a New ispLEVER Project


Task 1: Creating a New ispLEVER ProjectAs a first step, you will create a new project in ispLEVER.

To create a new ispLEVER project:

1. In the following directory, create a folder called lm32_tutor:

<ispLEVER_install_path>\examples\Tutorial

2. On your PC desktop, choose Start > Programs > Lattice Semiconductor > ispLEVER Project Navigator.

3. In the Project Navigator, select File > New Project to open the Project Wizard dialog box.

4. In the Project Wizard dialog box, shown in Figure 4, select or specify the following:

a. In the Project Name box, enter platform1.

b. In the Location box, enter the following directory:

<ispLEVER_install_path>\examples\Tutorial\lm32_tutor

c. In the Design Entry Type box, select Verilog HDL.

d. In the Synthesis Tools box, select Synplify.

e. In the Simulator Tools box, select ModelSim.

f. Click Next.

Note

If you want to preserve the original tutorial design files, save the lm32_tutor directory to another location on your computer before proceeding.

Figure 4: Project Wizard Dialog Box

LatticeMico32 Tutorial Task 1: Creating a New ispLEVER Project


5. In the Project Wizard - Select Device dialog box, shown in Figure 5, do the following:

a. In the Family box, choose LatticeECP.

b. In the Device box, choose LFECP33E.

c. In the Speed grade box, choose -4.

d. In the Package Type box, choose FPBGA484.

e. In the Operating Conditions box, choose Commercial.

f. Click Next to open the Project Wizard - Add Source dialog box.

6. In the Project Wizard - Add Source dialog box, click Next.

7. In the Project Wizard - Project Information box, click Finish.

The Project Navigator looks like the illustration shown in Figure 6.

Figure 5: Project Wizard - Select a Device Dialog Box

Note

Click on the part name, LFECP33E-4F484C, in the Sources in Project pane to see the contents of the Processes for Current Source pane.

LatticeMico32 Tutorial Task 2: Creating the Microprocessor Platform


Task 2: Creating the Microprocessor PlatformYou use MSB to create the microprocessor platform, which is the embedded microprocessor in a system-on-a-chip (SoC) design and the attached components, buses, component properties, and their connectivity. The microprocessor platform also specifies the parameters that customize the microprocessor and the attached components.

Creating a New MSB PlatformNow you will create a new platform in MSB.

To create a new platform:

1. Select Tools > LatticeMico32 System from the Project Navigator or click .

Figure 6: Project Navigator



The Workspace Launcher dialog box now appears, as shown in Figure 7.

The LatticeMico32 System interface that you are about to open stores in a workspace folder the preferences and options that you set in its interface tabs. In the Select Workspace dialog box, you must specify the name and location of this folder. Each instance of the interface has its own workspace folder. If you already have one or more LatticeMico32 System applications open and want to open another one, you must specify in the Select Workspace dialog box a workspace folder different from that of the previous interface instances.

The workspace directory is not the same directory in which you store the files generated by the tutorial.

2. In the Workspace box, specify the location of the workspace directory.

3. If you want the directory that you just specified to be the default, select the Use this as the default and do not ask again box.

4. Click OK.

Figure 7: Workspace Launcher



The LatticeMico32 System interface now appears, as shown in Figure 8.

5. In the upper left-hand corner of the graphical user interface, select MSB, if it is not already selected, to open the MSB perspective.

6. Choose File > New Platform.

7. In the New Platform Wizard dialog box, do the following:

a. In the Platform Name box, enter platform1.

b. In the Directory box, browse to the following directory and click OK:

<ispLEVER_install_path>\examples\Tutorial\lm32_tutor

c. In the Device Family box, select ECP from the pull-down menu.

d. In the Platform Templates box, select blank.

Templates are pre-created platforms that facilitate rapid development. They target the LatticeMico32/DSP development board. Each platform also has an associated constraint file that you can import into ispLEVER to avoid the effort of creating a constraints file. MSB gives you the flexibility of creating and adding your own custom templates and associated constraints files for the LatticeMico32/DSP

Figure 8: LatticeMico32 System Interface



development board or a custom board, in addition to using the templates provided as part of the installation package.

The New Platform Wizard dialog box should look like the illustration in Figure 9.

e. Click Finish.

Figure 9: New Platform Wizard Dialog Box



The MSB perspective now appears, as shown in Figure 10.

The MSB perspective consists of the following views:

Available Components view, which displays all the available components that you can use to create the design:

A list of hardware components: microprocessors, memories, components, and bus interfaces. Bus interfaces can be masters or slaves (see “Specifying the Connections Between Master and Slave Ports” on page 20 for more information on masters and slaves). The component list shown in Figure 10 is the standard list that is given for each new platform.

A list of preconfigured systems: demonstrations and pre-verified configurations for a given development board or a configuration that you previously built

You can double-click on a component to open a dialog box that enables you to customize the component before it is added to the design. The component is then shown in the Editor view.

Editor view, which is a table that displays the components that you have chosen in the Available Components view. It includes the following columns:

Name, which displays the names of the chosen components and their ports

Connection, which displays the connectivity between master and slave ports

Base, which displays the start addresses for components with slave ports. This field is editable.

Figure 10: MSB Perspective

Available Components view

Editor view

Component Attributes view

Console view or Component Help view



End, which displays the end addresses for components with slave ports. This field is not editable. The value of the end address is equivalent to the value of the base address plus the value of the size.

Size, which displays the number of addresses available for component access. This field is editable for the LatticeMico32 on-chip memory (EBR) and the LatticeMico32 asynchronous SRAM controller components only.

Lock, which indicates whether addresses are locked from any assignments. If you lock a component, its address will not change if you select Platform Tools > Generate Address.

IRQ, which displays the interrupt priorities of all components that have interrupt lines connected to the LatticeMico32 microprocessor. The LatticeMico32 microprocessor can accept up to 32 external interrupt lines.

Disable, which indicates whether components are temporarily excluded from the design

Component Help view, which displays information about the component that you selected in the Available Components view. It displays the name of the component, for example, “LatticeMico32 Timer” or “LatticeMico32 UART”; a brief description of the function of the component; and a list and explanation of the parameters in the dialog box that appears when you double-click on the component. If you click on the icon next to the component name, you can view a complete description of the component in a PDF file.

Console view, which displays informational and error messages output by MSB

Component Attributes view, which displays the name, parameters, and values of the component selected in the Available Components view or the Editor view. This view is read-only.

Selecting the Microprocessor Core The first step in building the platform is to add the microprocessor core. In this release, only the LatticeMico32 microprocessor is available.

You will be using the default cache setting for this task. Refer to the LatticeMico32 System online Help for information on non-cache settings.

To add the microprocessor core:

1. Under CPU in the Available Components view, click on LatticeMico32 to view the information available about the LatticeMico32 microprocessor.

Information about the LatticeMico32 microprocessor, including the parameters that you can set for it, now appears in the Component Help, or LatticeMico32, view and in the Component Attributes view in the lower third of the screen. If you click on the icon in the Component Help view, you can view a complete description of this component in a PDF file.

Similarly, if you click on this icon for a memory or a peripheral component, you can view information about that component.



2. Double-click on LatticeMico32 to add the microprocessor to the design. Alternatively, you can click on LatticeMico32, then click on the Add Component to Platform button ( ) to add the microprocessor.

The Add LatticeMico32 dialog box appears, as shown in Figure 11. The parameters in this dialog box correspond to those shown in the table in the Component Help view.

The software application developed in this tutorial will be deployed in the parallel flash memory. The goal is to have LatticeMico32 execute the code in the parallel flash memory when configuration of the FPGA is completed. To achieve this goal, the reset address used by LatticeMico32 must point to the flash address. At this point, you have not selected the flash device (and therefore the address), so you will reserve 0x02000000 for the flash.

3. In the Add LatticeMico32 dialog box, do the following:

a. To set the LatticeMico32 reset vector to the flash address, type 0x02000000 in the Location of Exception Handlers box.

This step sets the reset exception address, which is the address from where the microprocessor will begin fetching instructions at power-up.

b. Click OK to accept the default settings for the rest of the options.

Information about the microprocessor now appears in the Name, Connection, Base, End, and Size columns of the table in the Editor view.

Figure 11: Add LatticeMico32 Dialog Box



Adding the Off-Chip MemoryNext you will add the LatticeMico32 asynchronous SRAM controller and the parallel flash memory.

Adding the Asynchronous SRAM ControllerThe LatticeMico32 asynchronous SRAM controller is required to download and execute the software application code. The LatticeMico32/DSP development board has two 4-megabit asynchronous SRAM modules organized as 256K x 32, giving a total of 1 megabyte of asynchronous SRAM memory. This SRAM shares the data and address buses with the on-board parallel flash memory chips that are organized as 8M x 32. The wen and oen common control signals are also shared, although each memory type (SRAM, parallel flash memory) has its own chip select.

To add the asynchronous SRAM memory to the platform:

1. Under Memory in the Available Components view, double-click on Async SRAM to add the memory. Alternatively, you can click on Async SRAM, then click on to add the memory.

The Add Async SRAM dialog box appears, as shown in Figure 12.

The SRAM size is 1 megabyte. However, it shares the address bus with the flash device pair. The address bus size will be adjusted to the correct width when the flash memory peripheral is configured later in the tutorial.

2. Accept the default settings in the dialog box, and click OK.

Figure 12: Add Async SRAM Dialog Box

Note

You can delete a component from the Editor view by right-clicking on the component in the Editor view and selecting Remove Component from the pop-up menu. If you cannot remove a component, this command will be unavailable on the menu.



Adding the Parallel Flash MemoryThe LatticeMico32/DSP development board has two 16-bit-wide, 16-megabyte Common Flash Interface (CFI) parallel flash components. These two flash devices together appear as a 8M x 32 flash component. This flash pair will be used for software deployment.

To add the parallel flash component to the platform:

1. Under Memory in the Available Components view, double-click on Parallel Flash. Alternatively, you can click on Parallel Flash, then click on to add the component.

2. In the Add Parallel Flash dialog box, shown in Figure 13, do the following:

a. In the Base Address box, change the address to 0x02000000 to match the LatticeMico32 microprocessor’s Exception Handler address (shown in Figure 11 on page 15) so that on power-up the microprocessor obtains instructions from this flash component.

b. In the Size box, change the size to 33554432, as shown in Figure 13.

c. Click OK to accept the default settings for the rest of the options.

The flash address bus is shared with the SRAM address bus. The flash is addressed as 8Mx32, but the address width must be wide enough to address 32Mx8, so 25 address bits are required. Make sure the FLASH Address Width option is set to 25 bits wide to ensure that there are enough address bits to access the 1Mx8 SRAM block and the 32Mx8 flash memory block.

Figure 13: Add Parallel Flash Dialog Box



Adding the Peripheral ComponentsNow you will add the peripheral components to the platform.

Adding the GPIOThe first component that you will add is the LatticeMico32 GPIO component, which provides a memory-mapped interface between a WISHBONE port and general-purpose I/O ports. The I/O ports connect either to on-chip user logic or to I/O pins that connect to devices external to the FPGA.

To add the GPIO to the platform:

1. Under IO in the Available Components view, double-click on GPIO. Alternatively, you can click on GPIO, then click on to add the peripheral.

2. In the Add GPIO dialog box, shown in Figure 14, do the following:

a. In the Instance Name box, change the name of the GPIO to LED.

For this tutorial, the GPIO block must be named LED. Failure to name the GPIO block LED will cause mismatches in the FPGA I/O pin names. The example C source code uses the instance name to access the GPIO registers.

b. Change the setting of the Data Width option to 10.

c. Click OK to accept the default settings for the rest of the options.

Figure 14: Add GPIO Dialog Box



Adding the UARTThe final component that you will add is a LatticeMico32 universal asynchronous receiver-transmitter (UART), a core that contains a receiver and a transmitter. The receiver performs serial-to-parallel conversion of the aysnchronous data frame received at its serial data input pin. The transmitter performs parallel-to-serial conversion on the 8-bit data received from the CPU.

To add the UART to the platform:

1. Under IO in the Available Components view, double-click on UART. Alternatively, you can click on UART, then click on to add the component.

2. In the Add UART dialog box, shown in Figure 15, click OK to accept the default settings.

Figure 15: Add UART Dialog Box



The MSB perspective now resembles the illustration in Figure 16.

Specifying the Connections Between Master and Slave PortsThe connections that you will make between the master and slave ports in the Editor view will reflect the access scheme shown in Figure 1 on page 3.

The following information applies to master and slave ports in the Editor view:

There are two types of ports: master ports and slave ports.

A master port can initiate read and write transactions.

A slave port cannot initiate transactions but can respond to transactions initiated by a master port if it determines that it is the targeted component for the initiated transaction.

A master port can be connected to one or more slave ports.

A component can have one or more master ports, one or more slave ports, or both.

Horizontal lines with outbound arrows emanating from a component port indicate a master port.

Figure 16: MSB Perspective After Addition of All Components



Horizontal lines with inbound arrows targeting a component port indicate a slave port.

The vertical lines are associated with horizontal lines with outbound arrows (that is, master ports) to facilitate "connectivity" from a master port to a slave port. A circle represents the intersection of the vertical line and a horizontal line associated with a slave port.

A filled circle indicates a connection between the master port represented by the vertical line and the slave port represented by the horizontal line associated with the filled circle.

A hollow circle indicates an absence of connection between the master port represented by the vertical line and the slave port represented by the horizontal line associated with the hollow circle.

The numbers next to the lines representing the master ports are the priorities in which the master ports can access the slave ports. You can change the priority of these connections by following the instructions in the online Help for LatticeMico32 System.

To specify the connections between master and slave ports:

1. Connect the instruction and data ports to the LatticeMico32 asynchronous SRAM controller slave port by clicking on both circles in the Connection column in the ASRAM Port row.

2. Connect the data port to the LatticeMico32 GPIO slave port by clicking on the circle in the Connection column in the GP I/O Port row.

3. Connect the instruction and data ports to the LatticeMico32 parallel flash slave port by clicking on both circles in the Connection column in the Data Port row.

4. Connect the data port to the LatticeMico32 UART slave port by clicking on the circle in the Connection column in the UART Port row.

Figure 17 shows the resulting connections in the Editor view. The master ports are represented by black lines, and the slave ports are represented by blue lines. Both the instruction and data ports connect to the LatticeMico32 asynchronous SRAM controller and the parallel flash controller, but only the data port connects to the LatticeMico32 GPIO, the LatticeMico32 parallel flash controller, and the LatticeMico32 UART.

Figure 17: Connecting the Instruction and Data Ports to the Slave Ports

Master ports

Slave ports



Figure 18 shows the connections generated by MSB. MSB automatically generates the arbiter when it generates the microprocessor platform to allow multiple master ports access to multiple slave ports over a single shared bus. In the diagram, the instruction port accesses the LatticeMico32 Asynchronous SRAM controller and the flash controller. The data port accesses the LatticeMico32 asynchronous SRAM controller, the LatticeMico32 GPIO, the LatticeMico32 parallel flash controller, and the LatticeMico32 UART.

Assigning Component AddressesThe next step is for MSB to generate an address for each component with slave ports. Addresses are specified in hexadecimal notation. Components with master ports are not assigned addresses.

In this case, you will not assign individual addresses. You will perform the address generation procedure solely as a prerequisite for generating the microprocessor platform.

Since you have explicitly assigned an address to the parallel flash component, you will lock this address so that MSB will not automatically assign it a new address. You do not want the flash address to change, because that is where the final software application code will reside. It is also

Figure 18: Connections Generated by MSB

LM32 CPU (master ports)

Instruction port

Data port

Shared Bus Arbiter

UART slave device (for host communication)

Data port

Instruction port

SRAM slave device (memory for code and data)

GPIO slave device (for controlling LEDs)

Parallel flash memory (for deploying the application code)

Note

You can only edit the addresses in the Base column. You cannot edit the addresses in the End column. The value of the end address is equivalent to the value of the base address plus the value of the size.



the address for the microprocessor reset exception (that is, the power-up address) as configured when the microprocessor component is added.

To lock the addresses:

In the Lock column, select the box for the parallel flash (flash).

To automatically assign component addresses:

Choose Platform Tools > Generate Address, or click the Generate Base Address button ( ), or right-click in the Editor view and choose Generate Address from the pop-up menu.

The addresses now appear in the Base and End columns in the Editor view, in hexadecimal notation. Slave components that are not memories must reside within the 0x80000000-0xFFFFFFFF memory range. The Generate Address command sets A31-A28 of each of these slave components to 0x8.

Note

Address and size values that appear in italic font in the Editor view cannot be changed.



Your MSB perspective should now resemble the example shown in Figure 19. The base addresses that you see in your Editor view may be different from those shown in Figure 19.

Figure 19: MSB Perspective After Assignment of Addresses



Assigning Interrupt Request PrioritiesThe interrupt request priority is the order in which hardware components request computing time from the CPU. Now you will assign an interrupt request priority (IRQ) to all components that feature a dash in the IRQ column of the Editor view. You cannot assign interrupt priorities to components lacking this dash in the IRQ column, such as memories and CPUs.

To assign interrupt priorities for all components other than memories:

Choose Platform Tools > Generate IRQ, or click the Generate IRQ button ( ), or right-click in the Editor view and choose Generate IRQ from the pop-up menu.

If you accidentally assign duplicate priorities, MSB will issue an error message in the Console view when you select Platform Tools > Generate IRQ.

Performing a Design Rule CheckYou will want to perform a design rule check to verify the addressing.

To perform a design rule check:

Choose Platform Tools > Run DRC, or click the Run DRC button ( ), or right-click in the Editor view and choose Run DRC from the pop-up menu.

In the Console view, MSB shows that there are no errors in the platform.

Generating the Microprocessor PlatformYou are now ready to generate the microprocessor platform. During the generation process, MSB creates the following files:

A platform1.v (Verilog) file, which is the top-level simulation and synthesis RTL file passed to ispLEVER. It includes the .v files for each component in the design. They are used to synthesize and generate a bitstream to be downloaded to the FPGA. The .v files for each component reside under the top-level platform1.v file.

A platform1.msb file, which is a configuration file in XML format that contains the configurable parameters and bus interface information for the components. It is passed to C/C++ SPE.

In addition, the generation process saves the design and makes these files available to ispLEVER.

Note

To reassign an interrupt priority for a specific component, go to the IRQ column in the row for the component, click on the current interrupt priority number, and choose the new priority number from the drop-down menu. Explicitly assigned interrupt priorities will not be overridden by the generator. Checking the Lock box does not lock the automatically assigned interrupt priority.



To generate the microprocessor platform:

Click anywhere in the Editor view and choose Platform Tools > Run Generator, or click the Run Generator button ( ), or right-click and choose Run Generator from the pop-up menu.

The Console view displays the output as MSB processes the design.

MSB now generates the platform1.msb and top-level platform1.v files. You will see Finish Generator in the Console view when the generator is finished.

If you edit the .msb file after it has been generated, save it by choosing File > Save As. An asterisk (*) preceding platform1.msb above the Editor view indicates that the platform1.msb file has been edited.

The MSB perspective now looks like the illustration in Figure 20. The assigned addresses for the components other than the parallel flash may differ.

Figure 20: MSB Perspective After Building the Microprocessor Platform



Figure 21 shows the structure of the directory that MSB generates in the background. The contents of this directory are dynamically generated, and any changes to them are overwritten from build to build.

Note

Only the relevant files are shown in Figure 21, along with a sample of the component directories.



Figure 21: MSB Directory Structure

<install_path>

examples

Tutorial

lm32_tutor

platform1

components

soc

lm32_top

rtl

verilog

lm32_top.v and other *.v files

platform1.msb

platform1.v

asram_top

uart_core

drivers

device

peripheral.mk file

*.c, *.h files

Platform project directory

Components repository

Hardware implementation

Software implementation

Platform definition/implementation directory

Platform definition (also for software flow)

Platform implementation (for ispLEVER)

LatticeMico32-specific make files for managed-make software builds

gnu

platform1_inst.v Platform implementation (for ispLEVER)

gpio

LatticeMico32 Tutorial Task 3: Generating the Microprocessor Bitstream


As shown in Figure 21, MSB generates a platform1_inst.v file, which contains the Verilog instantiation template to use in a design where the platform is not the top-level module. Figure 22 gives this template for the platform1 platform.

Task 3: Generating the Microprocessor BitstreamNow you will return to ispLEVER to import the Verilog file generated by MSB and to specify the connections from the microprocessor to the chip pins by importing an .lpf file. You can optionally perform functional simulation and timing simulation. Finally, you will build the database; map, place, and route the design; and generate the bitstream to download to the chip on the board.

Importing the Verilog FileFirst, you must import the platform1.v Verilog file output by MSB.

To import the Verilog file output by MSB:

1. In the ispLEVER Project Navigator, choose Options > Environment.

2. Click on the General tab.

Figure 22: Verilog Template

platform1 platform1_u (.clk_i(clk_i),.reset_n(reset_n), .sramsram_csn(sramsram_csn) //, .sramsram_be(sramsram_be) // [3:0], .flashsram_csn(flashsram_csn) //, .flashsram_be(flashsram_be) // [3:0], .flashsram_byten(flashsram_byten) //, .flashsram_wpn(flashsram_wpn) //, .flashsram_rstn(flashsram_rstn) //, .LEDPIO_OUT(LEDPIO_OUT) // [10-1:0], .uartSIN(uartSIN) //, .uartSOUT(uartSOUT) //, .sramflashOEN(sramflashOEN), .sramflashWEN(sramflashWEN), .sramflashADDR(sramflashADDR)// [24:0], .sramflashDATA(sramflashDATA)// [31:0]);



3. If the Copy source file to project directory for Source-Import command is selected, turn it off, as shown in Figure 23, and click OK.

4. Choose Source > Import.

5. In the Import File dialog box, browse to the following location, select the platform1.v file for the File Name box, and click Open.

<ispLEVER_install_path>\examples\Tutorial\lm32_tutor\platform1\soc\platform1.v

6. In the Import Source Type dialog box, select Verilog Module and click OK.

7. In the Choose Top Module dialog box, select platform1 from the drop-down menu and click OK.

Connecting the Microprocessor to the FPGA PinsYou have two options for connecting the microprocessor to the FPGA pins:

Manually create the pin constraints and import them into ispLEVER.

Import a pre-created constraints file that is part of the platform templates into ispLEVER.

For brevity, this tutorial allows you to import into ispLEVER the pin constraints specified for the PlatformE template platform, since you will be using PlatformE. MSB copies the .lpf file associated with a platform template, if it exists, into the \soc directory.

To import the .lpf file:

1. In the Project Navigator, right-click on Build Database and select Properties.

Figure 23: Environment Options



2. In the Properties dialog box, set Consistent Bus Name Conversion to true.

3. Click Close.

4. In the Project Navigator, choose Source > Import Constraint/Preference File.

5. In the Import Preference File dialog box, browse to the following directory, select the PlatformE.lpf file for the File Name box, and click Open.

<ispLEVER_install_path>\micosystem\platforms\PlatformE\ECP\HPE_MINI.lpf

6. In the prompt box that features a line similar to The current constraint file is saved as c:\isptools\examples\tutorial\lm32_tutor\ platform1.lpf.bak, click OK.

7. In the prompt box that says Do you want to reset the project update status?, click Yes.

Performing Functional SimulationYou can optionally simulate the functionality of the output top-level platform1.v module by using ModelSim in ispLEVER. See the ModelSim Lattice User’s Manual for more information on this procedure.

Performing Timing SimulationYou can optionally validate the timing of your design by performing timing simulation. Because timing simulation is a complex topic, it is not addressed in this tutorial. For information on timing simulation, see the Achieving Timing Closure in FPGA Designs Tutorial, the “Design Verification” topic in the online flow Help, or the “Strategies for Timing Closure” chapter of the FPGA Design Guide.

The timing simulation process automatically builds a database and maps, places, and routes the design.

Generating the BitstreamNow you will generate a bitstream to download the microprocessor platform to the FPGA. If you did not perform timing simulation, the bitstream generation process automatically synthesizes, maps, places, and routes the design before it generates the bitstream.

To generate a bitstream (.bit) file:

1. In the Sources in Project pane of the Project Navigator, highlight the part name, LFECP33E-4F484C.

2. Double-click Generate Bitstream Data.

IspLEVER now generates a bitstream data file, platform1.bit, that is ready to be downloaded into the device. This process takes several minutes. The

LatticeMico32 Tutorial Task 4: Downloading the Hardware Bitstream to the FPGA


Project Navigator shows the completion of each process, as shown in Figure 24.

Task 4: Downloading the Hardware Bitstream to the FPGA

The bitstream file generated in the previous section contains all the information required to program the LatticeECP FPGA. Lattice Semiconductor provides a program, ispVM System, that sends the programming bitstream to the FPGA over a parallel port or USB port communications link. Now you will use ispVM System to download the hardware bitstream that you generated in the previous section to the FPGA on the board. For instructions on connecting the USB cable to the board, refer to the LatticeMico32 Development Kit User’s Guide.

To download the bitstream to the FPGA on the board:

1. Remove any Lattice USB ispProgramming cables from your system.

2. Connect a USB cable from your computer to the LatticeMico32/DSP development board. The USB cable must be connected to the USB target

Figure 24: Project Navigator After Bitstream Generation



connector adjacent to the keypad. Give the computer a few seconds to detect the USB device on the LatticeMico32/DSP development board before moving to step 3.

3. In the Project Navigator or in the MSB perspective, choose Tools > ispVM System or click on . Alternatively, you can choose Start > Programs > Lattice Semiconductor > Accessories > ispVM System.

4. Choose Options > Cable and I/O Port Setup to set up your cable.

5. In the Cable and I/O Port Setup dialog box, shown in Figure 25, do the following:

a. In the Cable Type box, select USB.

b. In the Port Setting box, choose the only setting available in the drop-down menu, EzUSB-0.

c. Click OK.

6. In ispVM, choose ispTools > Scan Chain or click the Scan button.

The New Scan Configuration Setup window appears with LFEC/ECP33E in the Device list.

7. Double-click the FileName/IR-Length field next to LFEC/ECP33E.

Note

A USB cable is included with the board.

Note

If ispVM is not installed on your system, go to the Lattice Semiconductor Web site to download it.

Figure 25: Cable and I/O Port Setup Dialog Box



8. In the Multi Match Device’s ID List, select LFECP33E.

The Device Information dialog box now comes up.

9. In the Device Information dialog box, do the following:

a. In the Data File box, browse to the platform1.bit file in the following directory, and click Open.

<install_path>\examples\Tutorial\lm32_tutor\platform1.bit

b. In the Operation box, select Fast Program.

c. In the Device Access Options box, select JTAG 1532 Mode from the pull-down menu.

The Device Information dialog box should resemble the illustration shown in Figure 26.

d. Click OK.

10. Click the Go button in the ispVM toolbar to initiate the download.

A processing status bar shows you the progress of the download.

Figure 26: Device Information Dialog Box

LatticeMico32 Tutorial Task 5: Creating the Software Application Code


11. Check the New Scan Configuration Setup window to see if the download passed, as shown in Figure 27.

At the end of this process, the FPGA is loaded with the microprocessor hardware configuration.

Task 5: Creating the Software Application CodeIn this task, you create the software application by using C/C++ SPE in LatticeMico32 System. The software application is the code that runs on the LatticeMico32 microprocessor to control the components, the bus, and the memories. The application is written in C/C++.

C/C++ SPE is based on the Eclipse environment and provides an integrated development environment for developing, debugging, and deploying C/C++ applications. The C/C++ SPE tool chain uses the GNU C/C++ tool chain (compiler, assembler, linker, debugger, and other necessary utilities) customized for the LatticeMico32 microprocessor.

C/C++ SPE uses the same LatticeMico32 System interface as MSB, but it uses a different perspective called the C/C++ perspective.

To activate the C/C++ perspective:

In the upper left-hand corner of MSB graphical user interface, select C/C++.

Figure 27: New Scan Configuration Setup Window After the Downloading of the Bitstream

Note

If you want to save this programming configuration for future use, you can save it in an .xcf file. Choose File > Save, and in the Save As .XCF File dialog box, browse to the location where you want to save the .xcf file, type the name of the .xcf file in the File Name box, and click Save.



The C/C++ perspective is shown in Figure 28.

The C/C++ perspective consists of the following views:

C/C++ Projects view, which lists C/C++ SPE projects that have been created

Navigator view, which shows all of the file system's files under the workspace directory

Editor view, which is identical to the Editor view in the MSB perspective

Outline view, which displays the structure of the file currently open in the Editor view

Problems view, which displays any error, warning, or informational messages output by C/C++ SPE

Console view, which displays informational messages output by the C/C++ SPE build process

Properties view, which displays the attributes of the item currently selected in the Projects view. This view is read-only.

Search view, which displays the results of a search when you choose Search > Search

Tasks, which shows the tasks running concurrently in the background

Make Targets, which is not used

Figure 28: C/C++ Perspective

C/C++ Projects view or Navigator view

Problems view, Console view, Properties view, Tasks view, or Search view

Outline view

Editor view



Creating a New C/C++ SPE ProjectYou will create a new project in C/C++ SPE, import the platform1.msb file into the project, select the application code template to use so you do not have to write the code yourself, and compile the code.

To create a new C/C++ SPE project:

1. In the C/C++ perspective, choose File > New > Mico32 Managed Make C Project.

2. In the New Project dialog box, do the following:

a. In the Project Name box, enter LEDTest.

b. In the MSB System box, browse to the following location, select the platform1.msb file, and click Open.

<ispLEVER_install_path>\examples\Tutorial\lm32_tutor\platform1\soc\platform1.msb

c. In the Select Project Templates box, select LEDTest as the template for the application code.

Note

Templates are packaged software application files that are copied to the new project and provide a starting point for building an application. Some templates have specific requirements, as described in the description pane. If these hardware and software requirements are not met, the application built may not function correctly and may require you to debug the application by using the C/C++ SPE debug interface. C/C++ SPE enables you to create templates in addition to those included with the installation.



The New Project dialog box should resemble the figure shown in Figure 29.

d. Click Finish.

Figure 29: New Project Dialog Box

Note

The directory shown in the Location box in the Project Contents field is where the software project directory will be created. Your user files will be placed in this directory.



Now you see the source code in the middle pane of the C/C++ perspective, as shown in Figure 30.

Selecting Linker Memory SettingsAn application image contains sections called linker sections. Some of these sections, such as the software application code (that is, instructions for the microprocessor) and unmodifiable constants, are not modified by the application. These sections can reside in either a read-only memory region, such as the flash at run time, or a read/write memory region, such as asynchronous memory. Other sections, such as uninitialized variables and the stack required by the application, must reside in read/write memory. C/C++ SPE provides you with an easy-to-use feature for selecting memories for such regions.

Your platform contains two memory components: a parallel flash memory and an asynchronous SRAM memory. You will build the LEDTest application to run from the asynchronous SRAM memory; that is, the final executable will store all its linker sections in the SRAM memory region.

To select linker sections:

1. Choose Project > Properties.

Figure 30: Source Code in C/C++ Perspective



The Properties for LEDTest dialog box now appears, as shown in Figure 31.

In the left-hand pane, you can open one of the following panes:

The Info pane provides basic project location information.

The Builders pane provides information on the builder system used for this managed build project. It is preconfigured to use the LatticeMico32 builder system. It should not be modified.

C/C++ Build pane enables you to select and manage the compiler, assembler, and linker settings.

The Platform pane provides information on the platform used by this project, in addition to other information such as the linker section setting.

The Project References pane enables you to manage other projects referenced by the current project. It is not used for the C/C++ SPE LatticeMico32 managed build environment.

2. Select the Platform pane.

Figure 31: Properties for LEDTest Dialog Box



The Properties for LEDTest dialog box now changes to the screen shown in Figure 32.

The Target Hardware Platform box shows the currently referenced MSB platform. You can change the hardware platform used by the software application, but you must rebuild the software application once you change it.

The options in the Linker Script section enable you to select your own linker script. However, for this tutorial you will use the default linker script. For the auto-generated linker script, you can specify the memories that will be used for the linker sections. The C/C++ SPE managed build process inspects the MSB platform specified to determine the available memory regions. As a default, the C/C++ SPE managed build process selects the largest read/write memory available to contain all the sections. For this tutorial, C/C++ SPE will select an SRAM for all the linker sections, because it is the largest read/write memory.

3. Click OK to return to the C/C++ perspective.

Compiling the ProjectThe next step is to build the project, in which C/C++ SPE compiles, assembles, and links your application code, as well as the system library code provided by C/C++ SPE.

To compile the project:

1. Click on LEDTest to select it in the C/C++ Projects view (left-hand pane).

Figure 32: Platform Pane of the Properties for LEDTest Dialog Box



2. Choose Project > Build Project. Do not click on any of the buttons in the Build Project dialog box.

This step generates the following files, among others:

A C header file, DDStructs.h, that describes the device-driver structures for the applicable devices, in addition to the relevant platform settings, such as the microprocessor clock frequency

A C source file, DDStructs.c, that describes the component instance parameters required by the device drivers in appropriate structures

A C source file, DDInit.c, that invokes specified device initialization routines for putting the relevant instantiated components in a known state

A linker script, linker.ld, that contains the location and size of the memory components and the rules for generating an executable file image, as required by the GNU linker. C/C++ SPE uses this information to ensure that the program code and data are located at the correct addresses. Although this tutorial does not include advanced topics, LatticeMico32 C/C++ SPE enables you to easily specify a custom linker script to be used in lieu of the generated script for the managed build.

A LatticeMico32 software executable file with an .elf extension. The .elf file contains the Mico32 instructions, debug information, and information about the pre-initialized data. This tutorial generates a file called platform1.elf.

These files are included in the directory that C/C++ SPE generates in the background. The structure of this directory is shown in Figure 33. The contents of this directory are dynamically generated, and any changes to them are overwritten from build to build.



The platform1 library directory shown in Figure 33 contains platform-specific information for the building of an application. Figure 34 shows the automatically generated files in this directory that are required to build an

Note

Only the most important files are shown in Figure 33.

Figure 33: C/C++ SPE Directory Structure

LEDTest

debug

*.elf

*.o

makefile

drivers.mk

debug

*.o

platform1

Project directory

Build configuration project output directory

Application executable

User-source object files

Application makefile

Makefile defining peripheral include/source paths for application

Output directory for platform sources compiled by application makefileLibrary source object files compiled by application makefile

Platform library directory

libplatform1.aPlatform library file containing platform-specific drivers



application. The contents of this directory are generated dynamically, and any changes to them are not preserved from build to build.

Note

Only the most important files are shown in Figure 34.

Figure 34: Platform Library Directory Structure

platform1

debug

drivers.mk

inherited_settings. mk

linker.ld

linker_settings.mk

makefile

platform_rules.mk

settings.xml

*.c/*.s

*.h

ddinit.c

ddstructs.c

ddstructs.h

crtoram.s

Platform library directory

Build-configuration platform library output directoryMakefile that identifies peripheral makefiles for library buildBuild settings inherited from application build settings

Makefile identifying linker script to use

Makefile for building platform library

Platform build variables inherited from application settings

Default linker script for this platform

Pklatform library build-settings file

Platform-specific driver sources

Platform-specific driver header files

Driver initialization source file

Peripheral instance-specific data structures

Peripheral-specific data structures

LatticeMico32 boot/startup assembly source file

system_conf.h System configuration manifest header file

LatticeMico32 Tutorial Task 6: Debugging and Executing the Software Application


Task 6: Debugging and Executing the Software Application Code on the Development Board

In this task, you will download the executable file containing the software application code to the LatticeMico32/DSP development board and allow the LatticeMico32 microprocessor, which was part of the FPGA bitstream used in “Task 4: Downloading the Hardware Bitstream to the FPGA” on page 32, to execute it.

This task assumes that you have successfully downloaded the platform FPGA bitstream to the development board in “Task 4: Downloading the Hardware Bitstream to the FPGA” on page 32.

Software Application Code Execution FlowThe order in which the LatticeMico32 microprocessor executes the software application code images is as follows:

1. The FPGA is configured to have a LatticeMico32 platform. The LatticeMico32 microprocessor starts execution at the address contained in its exceptions base address (EBA), which is given in the Location of Exception Handlers box in the Add LatticeMico32 dialog box.

2. The reset address in the EBA is the flash memory address. The flash memory initially contains unknown data.



Figure 35 illustrates this code execution flow.

3. When you start the LatticeMico32 System Debugger, it communicates with the microprocessor over the microprocessor's debug module. The debug module, in turn, generates a debug exception that causes the microprocessor to execute the debug monitor code. This debug monitor code then communicates with the LatticeMico32 System Debugger running on the host computer. At this point, the Debugger has control over the microprocessor and can access the platform's memory through the debug module or microprocessor to download the application to the selected memories. Once it has downloaded the application to be debugged to the target memory or memories, it sets the microprocessor's program counter to start executing the downloaded code.

Figure 35: Software Application Code Execution Flow

Parallel flash

PC (Debugger)

LEDTest.elf file

EBR

LEDTest (software application code) with breakpoint at main()

Debug monitor code

LM32JTAG UART

SRAM

Executing

FPGA

LED (GPIO)

LEDs



These latter steps are shown graphically in Figure 36.

Debugging the Software Application Code on the BoardWith the LatticeMico32 microprocessor, you can debug the developed software application code directly on the FPGA, using a suitable target board (product, development, or evaluation) that meets the requirements of the software development. This capability reduces software development time and iterations. However, if you choose, you can debug the software application code by using the instruction set simulator, as described in the LatticeMico32 Software Developer User’s Guide. This tutorial shows you how to take your software application code directly to hardware.

To debug the software application code on the board:

1. In the C/C++ SPE perspective, click LEDTest in the C/C++ Projects view (left-hand pane).

2. Choose Run > Debug.

Figure 36: Software Application Code Execution Flow, continued

Parallel flash

PC (Debugger)

LEDTest.elf file

EBR

LEDTest (software application code) with breakpoint at main()

Debug monitor code

LM32JTAG UART

SRAM

Executing

FPGA

LED (GPIO)

LEDs



The Debug dialog box opens, as shown in Figure 37.

3. In the left-hand pane of the dialog box, click mico32 hardware.

Figure 37: Debug Dialog Box



The dialog box now changes to resemble the dialog box shown in Figure 38.

Figure 38 shows two launch configurations:

The Debug configuration, also called the Debug Launch, allows you to control the debug process.

The Run configuration executes the application. You cannot use debug features with this launch. Use this configuration if you do not want to debug the software application code.

Each of these configurations can be associated with an Eclipse perspective that you can select by using the Debug or Run pull-down menus. For the debug launch configuration, the default perspective is the Debug perspective that allows access to debug functionality. Because this tutorial shows you how to debug an application, you will use the debug launch configuration.

4. Click New below the Configurations list box.

Figure 38: Debug Dialog Box with Hardware Selected



The appearance of the Debug dialog box changes again, as shown in Figure 39.

In this dialog box, you specify the project or executable to debug. Since you selected the project before selecting Run > Debug, the boxes are filled by Eclipse. If these boxes are not populated, follow these instructions to configure the items in the Main tab of this dialog box:

a. Use the Browse button to select the Eclipse project.

Clicking Browse activates a dialog box that lists the available projects created or imported in Eclipse.

b. Select LEDTest.

c. Click the Search Project button to select the executable (.elf) file that you want to debug.

A project may have multiple executables. Clicking the Search Project button activates a dialog box that lists the executables built for the project. If you want to use an executable not built within C/C++ SPE, click the Browse button to activate a file selection dialog box in which to select the appropriate .elf-format executable file.

Figure 39: Debug Dialog Box with Tabs



5. Click the Debugger tab of the Debug dialog box, shown in Figure 40.

The Debugger tab features the appropriate Debugger settings:

Startup option, which enables you to choose where you want your initial breakpoint. For debug launch, the Debugger downloads the code and sets an initial breakpoint to enable debugging. You can place your breakpoint either at the start of your main program or at the start of the Device Driver initialization routine generated by the C/C++ SPE managed build process. The default is the start of your main program.

Remote Target option, which provides the address for the LatticeMico32 debug proxy program that will be launched on your computer. This proxy program allows C/C++ SPE to debug the program by using the GNU GDB program to provide a communication channel to the microprocessor over a JTAG connection. Refer to the LatticeMico32 Software Developer User’s Guide for more details on the debugging setup.

Debugger option, which lists the debugger application that C/C++ SPE will use as the debugger. This setting cannot be changed.

If you attempt to change settings, the Apply button may become available. In this case, click the Apply button to save your settings.

6. Click the Debug button located on the lower right side of the dialog box.

When you click the Debug button, the dialog box closes, and C/C++ SPE appears engaged in activity. It is attempting to establish a connection to

Figure 40: Debugger Tab of the Debug Dialog Box



the debugger module on the microprocessor and to download the executable to the appropriate memory. Once it has successfully done this, the Confirm Perspective Switch prompt box containing the following message appears:

This kind of launch is configured to open the Debug perspective when it suspends. Do you want to open this perspective now?

7. Select the Remember my decision box, and click the Yes button. Click Yes in the prompt box.

Note

If you did not previously download the bitstream, a message box with the following error message may appear:

Check that the target FPGA contains an LM32 CPU with DEBUG_ENABLED equal to TRUE and that the FPGA has configured successfully.

Return to “Task 4: Downloading the Hardware Bitstream to the FPGA” on page 32, and download the bitstream before proceeding.

Note

Selecting Run > Debug on a computer running the Windows XP operating system may activate the Windows XP firewall. The Windows Security Alert dialog box shown in Figure 41 may appear.

Figure 41: Windows Security Alert Dialog Box

Click unblock to continue debugging.

TCP2JTAGVC is the application that provides the communication channel between the LatticeMico32 microprocessor debug module and lm32-elf-gdb (GDB modified for the LatticeMico32 microprocessor).



C/C++ SPE now switches to the Debug perspective, shown in Figure 42.

The Debug perspective consists of many views, some of which may not be visible:

Debug view, which displays the function calls made so far. It also contains application and process information.

Variables view, which displays the variables that are used in the source code functions

Breakpoints view, which appears when you insert a breakpoint

Source view, which displays the source code when you click on a thread in the Debug view

Outline view, which displays the functions in the source code

Console view, which displays the output of the debugging session

Tasks view, which is not used

Modules view, which displays the modules of the executable loaded. If you click on a module, C/C++ SPE displays all the functions that compose that module.

Registers view, which displays the registers in the CPU. It also shows the values on the registers at the breakpoints. Values that have changed are highlighted in the Registers view when your program stops.

Figure 42: Debug Perspective

Debug view

Variables view, Breakpoints view, Modules view, Registers view, Signals view, or Expressions view

Outline view or Disassembly view

Editor view or Source view

Console view or Tasks view or Memory view



Signals view, which enables you to view the signals defined on the selected debug target and how the Debugger handled each one

Memory view, which enables you to inspect and change multiple sections of your process memory

Expressions view, which is activated if you right-click in the Source view, choose Add Watch Expression, and enter a variable in the Add Expression dialog box

Disassembly, which shows the source code in assembly language with offsets. It shows the instructions that reside at each address.

To select views that are not visible for this perspective, click Window > Show View and choose the appropriate view.

8. Click on the + next to LEDTest in the Debug view, located at the top left, and expand the information shown until it resembles the illustration in Figure 43.

This expanded information shows the processes that are running as part of the debug launch—for example, the JTAG Server Process is running on the host PC, and the Debugger Process is running on the host PC.

Inserting BreakpointsThe information in the expanded Debug view under com.lattice.mdk.debug.mico32debugger contains information about the executable downloaded to the FPGA and executed by LatticeMico32. It shows that the execution is suspended because of a breakpoint at a line within the LEDTest.c source file.

1. In the Debug view, click on the statement containing the line 1 main() at….

This step activates the file in the Source view, located below the Debug view. A line with green highlighting shows the line at which the LatticeMico32 microprocessor has been suspended because of a breakpoint. The breakpoint is at the beginning of your main program, as configured for this debug launch.

You will now insert a breakpoint to check the software and platform functionality.

Figure 43: Expanded Debug View



2. In the LEDTest.c file displayed in the Source view, click on the line beginning with “MicoGPIOCtx_t,” as indicated in Figure 44.

3. Insert a breakpoint by double-clicking in the left margin, aligned to the line shown in Figure 44. Alternatively, you can select Run > Toggle Line Breakpoint.

As shown in Figure 45, LEDTest.c should now appear in the Source view with a blue bubble and a check mark in the margin aligned to the line of interest. If the Breakpoint view is open, it be should updated to show this breakpoint.

Executing the Software Application CodeNow you can resume executing the software application code on the board.

1. In the Debug view, click the green arrow to the right of the “Debug” tab title. Alternatively, you can choose Run > Resume.

The Debugger now issues a continue command to the LatticeMico32 microprocessor, which executes the code until it reaches the breakpoint that you inserted previously.

2. Step over the C source line by clicking the icon in the same line as the “Debug tab title. Alternatively, you can choose Run > Step Over or press the F6 key.

The Debugger causes the microprocessor to execute the source line at which the breakpoint was inserted.

Figure 44: Breakpoint Line

Figure 45: Inserted Breakpoint



At this point, the Variables view is updated, as shown in Figure 46.

The value of the “leds” variable may be different from that shown in Figure 46. However, if the value of the “leds” variable shown in Figure 46 is 0x00000000 (or 0) for your view, the platform most likely does not have a GPIO named LED in the platform. Re-perform the tutorial, following the procedures exactly.

3. In the Debug view, click the green arrow next to the tab title, or choose Run > Resume.

The Debugger issues a continue command to the LatticeMico32 microprocessor, which causes the microprocessor to continue execution of the downloaded code.

The Console view in the bottom of the C/C++ SPE window should display the text line shown in Figure 47. This text is output by the LEDTest application running on LatticeMico32, which uses the JTAG connection to the Debugger for standard input/output communication to the C/C++ SPE console.

4. Observe the LEDs on the LatticeMico32 development board to confirm a back-and-forth scrolling LED pattern, which is controlled by the code executed by LatticeMico32.

Note

If the Variables view is not visible, choose Window > Show View > Variables to make it visible. If the Variables view is inactive—that is, the tab is shown in gray tones—click on the Variables tab to make it active.

Figure 46: Updated Variables View

Figure 47: Console Output



5. Expand the Debug view to show the active processes, shown in Figure 48.

6. Click the line containing the text Thread[0] (Running) to activate the following two buttons:

A button with two orange bars, , located towards the center of the debug view title bar, which pauses execution. It inserts an asynchronous breakpoint similar to a pre-set line breakpoint.

A button with a red square, , which terminates the running application on LatticeMico32. The Debugger no longer provides access to the code being debugged. Use Run > Debug to restart the debugging session.

7. Click the red-square button to terminate execution of the LEDTest application on LatticeMico32.

8. Click the button on the top left of the Debug perspective window to return to the C/C++ perspective. Alternatively, you can select Windows > Open Perspective > C/C++ to return to the C/C++ perspective.

Figure 48: Running Processes



Modifying and Re-Executing the Software Application CodeThe LEDTest.c application contained some printf statements for test purposes. The platform is configured so that these printf statements communicate through the microprocessor’s debug module to the debugger running on the host machine for outputting information to theC/C++ SPE console. If the debugger is absent, the printf statements cause the debug module to wait indefinitely for a client to communicate with. Therefore, now that the code is validated and needs to be deployed, it must be devoid of printf statements.

1. Delete the printf statements from the code to make it similar to the example shown in Figure 49.

2. Choose File > Save to save the modified file.

3. Rebuild the modified code by selecting LEDTest, right-clicking, and choosing Rebuild Project.

Figure 49: Modified LEDTest Code

LatticeMico32 Tutorial Task 7: Deploying the Software Application Code to the


It is important that you terminate any prior debug session. If the Debugger is still paused or running, the Rebuild Project command will fail when the linker tries to overwrite the platform1.elf file.

4. Return to the Debug perspective.

5. To download, debug, and execute the modified code, do the following:

a. Click Run > Debug, then click Debug.

b. Click the green arrow next to the tab title.

c. Step over the C source line by clicking the icon in the Debug view or choose Run > Step Over or press the F6 key.

d. Click the green arrow again.

This code is now ready for stand-alone deployment in the parallel flash memory.

You have now completed the task of downloading and executing the software application code on the LatticeMico32/DSP development board.

6. Verify that the LEDTest program is functioning by noting the sweeping LED pattern on the board.

7. Click the Terminate ( ) button to stop the demonstration program, and unload the debug session. Failing to unload the debug session interferes with programming the parallel flash memory, a process that is described in the next session.

Task 7: Deploying the Software Application Code to the Parallel Flash Memory

As part of Task 6, you verified the functionality of the software application code. In this task, you will program the .elf file containing the software application code into the parallel flash memory, which is non-volatile memory.

Refer to the LatticeMico32 Software Developer User’s Guide for details on deployment strategies and user flow.

The LatticeMico32 System software includes example code for programming Common Flash Interface (CFI) parallel flash PROMs. This flash programming application will be used to program the LEDTest executable code into the parallel flash PROMs on the LatticeMico32/DSP development board.

Parallel Flash Memory Deployment FlowThe internal steps involved in deploying the software application code to the parallel flash memory are as follows:

1. The flash programmer application is built to run from the SRAM location.

2. The setup command in the flash programmer application is part of the Debugger to deploy LEDTest.elf to the parallel flash memory.



3. The setup command causes the Debugger to copy FlashProgrammer.elf to SRAM and then sets up the microprocessor to execute it.

Figure 50 illustrates this flow.

4. The flash programmer application, now executing on the LatticeMico32 microprocessor, reads the software application code (which has been converted on the PC to an image that will work from the parallel flash memory) from the PC and writes it to the parallel (CFI) flash memory.

Figure 50: Parallel Flash Memory Deployment Flow

Parallel flash

PC (Debugger)

LEDTest.elf file

EBR

Debug monitor code

LM32JTAG UART

Flash programmer

Executing

FPGA

LED (GPIO)

LEDs

SPI flash

Note

The address from which the LatticeMico32 microprocessor will read after reset is that of the parallel flash.



These steps are shown in Figure 51.

5. On reset, the LatticeMico32 microprocessor starts executing from the parallel flash memory, specifically the code locator code.

6. This code relocator reads the LEDTest instructions from the parallel flash memory and writes them into the SRAM.

7. After the software application is copied into the SRAM, the code locator code starts executing it.

Figure 51: Parallel Flash Memory Deployment Flow, continued

Parallel flash

PC (Debugger)

LEDTest.elf file

EBR

Debug monitor code

LM32JTAG UART

Executing

FPGA

LED (GPIO)

LEDs

SPI flash

Converted to flash location with prepend

LEDTest with code locator

Flash programmer

Note

The LEDTest image was originally developed to run out of this SRAM location.



These steps are illustrated in Figure 52.

Creating a CFI Flash Programmer ApplicationFor programming LEDTest to memory, a flash programmer must be available. Any platform that needs to retrieve instructions from non-volatile memory is capable of hosting a flash programmer application. The platform created in this tutorial includes a parallel flash component, so it is capable of hosting a flash programmer software application. The objective in this section is to deploy a software application in non-volatile memory as in a typical product deployment scenario.

C/C++ SPE provides a CFI flash programmer template, which can program binary data stored in a file on the host computer to any valid flash component.

The CFI flash programmer application relies on the device drivers for performing flash operations. They can be enhanced to support CFI flash configurations and command sets that are not currently supported. Refer to

Figure 52: Parallel Flash Memory Deployment Flow, continued

Parallel flash

PC (Debugger)

LEDTest.elf file

EBR

Debug monitor code

LM32JTAG UART

Flash programmer

Executing

FPGA

LED (GPIO)

LEDs

SPI flash

LEDTest with code locator

After reset



the LatticeMico32 Software Developer User’s Guide for an overview of the supported CFI flash configurations and command sets.

To prepare the flash programmer application:

1. Be sure the hardware bitstream is loaded on the board.

2. In the C/C++ perspective, choose File > New > Mico32 Managed Make C Project.

3. In the New Project dialog box, do the following:

a. In the Location box, browse to the following location:

<ispLEVER_install_path>\examples\Tutorial\lm32_tutor\

b. In the MSB System box, browse to the following location, select the platform1.msb file, and click Open.

<ispLEVER_install_path>\examples\Tutorial\lm32_tutor\platform1\soc\platform1.msb

c. In the Select Project Templates box, select CFIFlashProgrammer as the template for the application code.

d. In the Project Name box, enter FlashProgrammer.

The New Project dialog box should look like the example shown in Figure 53.

e. Click Finish.

Figure 53: New Project Dialog Box



4. Build the flash programmer application:

a. Follow the steps outlined in “Selecting Linker Memory Settings” on page 39: choose Project > Properties, select Platform, and click OK. Make sure that the flash programmer linker settings are set to use SRAM memory.

b. In the left-hand pane of the C/C++ perspective, click on FlashProgrammer, and choose Project > Build Project.

Preparing LEDTest for Flash DeploymentThe flash programmer application is a generic binary data programmer that reads data from a file on the host computer and programs it to a valid CFI flash memory.

The LEDTest executable is in .elf format and must be converted to binary data for the flash programmer to use. Also, since LEDTest was built for execution from SRAM, a code copier called the code locator must copy the binary format of LEDTest programmed in the parallel flash memory to SRAM and start executing it.

C/C++ SPE provides an easy-to-use interface for preparing LEDTest for flash deployment. Consult the LatticeMico32 Software Developer User’s Guide for functional details on the flash programming utility.

1. Be sure that FlashProgrammer is selected in the left-hand pane of the C/C++ perspective

2. In the C/C++ perspective, choose Tools > Software Deployment.



The Software Deployment dialog box appears with the Software Deployment Tools screen selected, as shown in Figure 54.

Just as with the debug launch configurations, two programming configurations are available:

Flash Deployment configuration, which provides a graphical user interface for preparing and programming an application to parallel flash memory

On-Chip Memory configuration, which provides a graphical user interface for preparing an application for deployment into on-chip memory. Refer to the LatticeMico32 Software Developer User’s Guide for this deployment strategy.

SPI Deployment, which provides a graphical user interface for preparing an application for deployment into a SPI flash component. Refer to the LatticeMico32 Software Developer User’s Guide for this deployment strategy.

3. Select CFI Flash Deployment, and click New.

Figure 54: Software Deployment Tools Dialog Box Showing Programming Configurations



The Software Deployment dialog box displays a flash programming configuration settings pane similar to that shown in Figure 55.

4. In the Name box, type LEDTestDeploy.

5. Click the Browse button next to the Project box.

The Project Selection dialog box comes up, as shown in Figure 56.

Figure 55: Software Deployment Dialog Box Showing Flash Programming Settings

Figure 56: Project Selection Dialog Box



6. Select LEDTest and click OK to select the project containing the executable that needs to be programmed to flash.

7. Click Search Project next to the C/C++ Application box.

The Program Selection dialog box appears, as shown in Figure 57. It contains the list of executables for the selected project, LEDTest.

8. From the Binaries list, select LEDTest.elf and click OK.

9. In the Platform CFI Flash Address box, enter 0x02000000, which is the base address for the flash component, as well as being LatticeMico32’s reset exception address.

The flash programmer uses this address to verify the presence of a flash device containing this absolute address. It uses device information contained as part of the device driver framework in this verification. It also uses this address to determine the offset within the flash device where it needs to program binary data.

10. Click the Browse button next to the Flash Programmer Application box.

A file selection dialog box appears.

11. Select the FlashProgrammer.elf file, located in the following directory, and click Open:

<ispLEVER_install_path>\examples\Tutorial\lm32_tutor\FlashProgrammer\Debug\FlashProgrammer.elf

12. Select the Prepend Code Relocator checkbox if it is not already selected.

As noted at the beginning of this section, the code relocator copies the binary format of LEDTest programmed in the parallel flash memory to

Figure 57: Program Selection Dialog Box



SRAM and starts executing it. For details on the code relocator, see the LatticeMico32 Software Developer User’s Guide.

The Software Deployment dialog box should resemble the illustration shown in Figure 58.

13. Click Apply to save the configuration if you want to reprogram the application with these settings.

14. Click Start.

Loading the parallel flash memory takes a few minutes. The flash programming utility now runs scripts that convert LEDTest.elf to binary data and prepend the code relocator that will copy the processed LEDTest binary image to SRAM. This code relocator is programmed at offset 0x02000000, that is, the microprocessor reset exception address. The code is therefore the first code executed on CPU reset. This code relocator copies the LEDTest code to SRAM. After copying the LEDTest code to SRAM, it branches to the starting address of the LEDTest code, effectively starting the execution of the LEDTest code.

After processing LEDTest.elf, the flash programmer utility downloads the flash programmer application, which reads the processed binary data and programs it to the appropriate flash location.

The console in the C/C++ perspective displays messages from the flash programmer as it progresses through flash programming. If the programmer encounters any errors, it displays the text in this console.

Figure 58: Software Deployment Dialog Box Showing Completed Flash Programming Settings



Consult the LattticeMico32 Software Developer User’s Guide for information on the implementation and functional details of the flash programming elements mentioned in this section.

As the programmer application executes successfully, you see a console display similar to the one shown in Figure 59. Depending on the size of LEDTest, the programming time may vary from a few seconds to a few minutes.

These messages disappear from the screen, but if you want to view them again, return to the Debug perspective and click on the highlighted terminated message in the Debug view, as shown in Figure 60. The messages will be displayed in the Console view of the Debug perspective.

After the flash programmer application finishes programming the data, you will see terminated messages in the Debug view of the Debug

Figure 59: Successful Flash Programming Console

Figure 60: Highlighted Terminate Message



perspective, as shown in Figure 61, and Client disconnected in the Console view. The console output also displays debug information.

15. To verify the successful programming of the LEDTest application, re-download the bitstream generated for this tutorial, following the instructions in “Task 4: Downloading the Hardware Bitstream to the FPGA” on page 32.

On download, the LEDs display the pattern generated by the LEDTest application, confirming that the flash was successfully programmed with LEDTest and its associated code relocator. The display also confirms that the code relocator successfully copied the LEDTest application in its binary format to the appropriate SRAM memory location.

Figure 61: Debug Perspective After Programming the Parallel Flash Memory with the Software Application Code

LatticeMico32 Tutorial Task 8: Deploying the Microprocessor Bitstream to SPI


Task 8: Deploying the Microprocessor Bitstream to SPI Flash Memory

As part of Task 7, you deployed the LEDTest application to non-volatile memory. The only task remaining to attain stand-alone deployment, as in an actual product deployment scenario, is to deploy the LatticeMico32 microprocessor to SPI flash memory, which is also non-volatile memory. This microprocessor is contained in the FPGA bitstream.

The LatticeMico32/DSP development board has an SPI flash that is used to store the FPGA configuration bitstream.

The LatticeMico32 Software Developer User’s Guide describes the steps required to deploy the FPGA bitstream generated in this tutorial, but they are duplicated here to complete the tutorial flow.

To deploy the microprocessor bitstream:

1. From the Debug perspective, choose Tools > ispVM or click on . Alternatively, you can choose Start > Programs > Lattice Semiconductor > Accessories > ispVM System.

2. Choose Options > Cable and I/O Port Setup to set up your cable.

3. In the Cable and I/O Port Setup dialog box, shown in Figure 62, do the following:

a. In the Cable Type box, select USB.

b. In the Port Setting box, choose the only setting available, EzUSB-0.

c. Click OK.

4. In ispVM, choose ispTools > Scan Chain or click the Scan button.

Figure 62: Cable and I/O Port Setup Dialog Box

LatticeMico32 Tutorial Task 8: Deploying the Microprocessor Bitstream to SPI


The New Scan Configuration Setup window appears with LFEC/ECP33E in the Device list.

5. Double-click the FileName/IR-Length field next to LFEC/ECP33E.

6. In the Multi Match Device’s ID List, select LFECP33E.

The Device Information dialog box now comes up.

7. In the Device Information dialog box, do the following:

a. In the Data File box, browse to the platform1.bit file in the following directory, and click Open.

<install_path>\examples\Tutorial\lm32_tutor\platform1.bit

b. In the Device Access Options pull-down menu, select SPI Flash Programming.

This step activates the SPI Serial Flash Device dialog box.

c. In the Select box, type SPI-M25P80, then click OK.

The Device Information dialog box should resemble the illustration shown in Figure 63.

d. Click OK in the Device Information dialog box.

8. Click GO in the New Scan Configuration Setup window.

Figure 63: Device Information Dialog Box

LatticeMico32 Tutorial Summary


IspVM System programs the SPI flash by means of the FPGA. The results are shown in Figure 64.

9. Disconnect and then reconnect the power supply.

The FPGA takes about three seconds to be programmed by the SPI flash.

When the FPGA is configured with the bitstream, LatticeMico32 comes into existence and starts executing the code from the parallel flash memory. This code is the code-relocator code that copies the LEDTest application to SRAM and then jumps to the starting address of the LEDTest application, achieving stand-alone deployment. You now see the red LED lights blinking.

SummaryYou have finished the LatticeMico32 Tutorial. In this tutorial, you have learned how to do the following:

Set up an ispLEVER FPGA project.

Create microprocessor platform for the LatticeMico32 embedded microprocessor in MSB.

Generate a bitstream of the microprocessor platform in ispLEVER and download it to the board with ispVM.

Download the hardware bitstream to the FPGA on the board.

Create the software application code for the microprocessor platform with C/C++ SPE.

Figure 64: New Scan Configuration Setup Window After Programming of the SPI Flash

Note

If you accidentally press the Reset button on your keypad, you will lose USB communication with the board, and the debugging will fail in both ispVM and MSB. To restore this communication, remove the power source from the board, re-connect the power source to the board, and use ispVM to reload the bitstream into the FPGA.

LatticeMico32 Tutorial Glossary


Debug and execute the software application code on the board.

Download the .elf file containing the software application code to the parallel flash memory.

Deploy the microprocessor bitstream to the SPI flash memory.

GlossaryFollowing are the terms and concepts that you should understand to use this tutorial effectively.

breakpoints. Breakpoints are a combination of signal states that are used to indicate when simulation should stop. Breakpoints enable you to stop the program at certain points to examine the current state and the test environment to determine whether the program functions as expected.

C/C++ SPE. C/C++ SPE is an abbreviation for the C/C++ Software Project Environment, which is an integrated development environment based on Eclipse for developing, debugging, and deploying C/C++ applications. The C/C++ SPE tool chain uses a GNU C/C++ tool chain (compiler, assembler, linker, debugger, and other utilities such as objdump) optimized for the LatticeMico32 process. It uses the same graphical user interface as MSB.

CDT. CDT is an abbreviation for C/C++ development tools, which are components, or plug-ins, of the Eclipse development environment on which the LatticeMico32 System is based.

CFI. CFI is an abbreviation for Common Flash Interface (CFI) parallel flash memory, which is an an open standard jointly developed by a number of chip vendors for a type of EEPROM that stores information without requiring a power source.

code-relocator code. Code-relocator code is code that copies the software application code to a destination memory and jumps to the application start address to run the application.

CSR. CSR is an abbreviation for a control and status register, which is a register in most CPUs that stores additional information about the results of machine instructions, for example, comparisons. It usually consists of several independent flags, such as carry, overflow, and zero. The CSR is mainly used to determine the outcome of conditional branch instructions or other forms of conditional execution.

debugging. Debugging is the process of reading back or probing the states of a configured device to ensure that the device is behaving as expected while in circuit. Specifically, debugging in software is the process of locating and reducing the errors in the source code (the program logic). Debugging in hardware is the process of finding and reducing errors in the circuit design (logical circuits) or in the physical interconnections of the circuits. The difference between running and debugging software is the placement of breakpoints in debugging.



Eclipse. Eclipse is an open-source platform that provides application frameworks for software application development. The LatticeMico32 System interface is based on the Eclipse environment.

.elf file. An .elf file is a file in executable linked format that contains the software application code written in C/C++ SPE.

GDB. GDB is an abbreviation for GNU Debugger, which is a source-level debugger based on the GNU compiler. It is part of the C/C++ SPE Debugger. It is connected to the various launch configurations connected to ISS or ispVM.

GNU Compiler Collection (GCC). The GNU Compiler Collection (GCC) is a set of programming language compilers. It is free software produced by the GNU Project.

HAL. HAL is an acronym for hardware abstraction layer, which is the programmer’s model of the hardware platform. It enables you to change the platform with minimal impact to your C code.

hardware debugger module. The hardware debugger module is a component of C/C++ SPE that is used to find problems in the software application.

hardware platform. A hardware platform is the embedded microprocessor in an SoC (system on a chip) design and the attached components, buses, component properties, and their connectivity.

IRQ. IRQ is an abbreviation for interrupt request, which is the means by which a hardware component requests computing time from the CPU. There are 16 IRQ assignments (0-15), each representing a different physical (or virtual) piece of hardware. For example, IRQ0 is reserved for the system timer, while IRQ1 is reserved for the keyboard. The lower the number, the more critical the function.

ISS. ISS is an abbreviation for instruction set simulator, which is a simulation model that imitates the behavior of a microprocessor. Often included in a debugger such as GDB, an ISS enables you to develop and debug a software program while the target hardware is still under development.

JTAG ports. JTAG ports are pins on an FPGA or ispXPGA device that can capture data and programming instructions.

.lpf file. The logical preference file (.lpf) is a post-synthesis FPGA constraint file that stores logical preferences that have been defined in the pre-map stage and post-map stage. This file is automatically generated when you create a new project in the Project Navigator, and it stores logical preferences only.

master port. A master port is a port that can initiate read and write transactions.

MSB. MSB is an abbreviation for Mico System Builder, which is an integrated development environment based on Eclipse for choosing components, such



as a memory controller and serial interface, to attach to the Lattice Semiconductor 32-bit embedded microprocessor. It also enables you to specify the connectivity between these elements. MSB then enables you to generate a top-level design that includes the microprocessor and the chosen components. It uses the same graphical user interface as C/C++ SPE.

.msb file. An .msb file is an XML-format file output by MSB.

perspective. A perspective is a combination of windows, menus, and toolbars in the LatticeMico32 System graphical user interface that enables you to perform a particular task. For example, the Debug perspective has views that enable you to debug the programs that you created in C++ SPE.

project. A project is the software application code written in C/C++ SPE.

PROM. Programmable read-only memory (PROM) is a permanent memory device that is programmed by the customer rather than by the device manufacturer. It differs from a ROM, which is programmed at the time of manufacture. PROMs have been mostly superseded by EEPROMs, which can be reprogrammed.

running. Running is the process of executing a software program.

slave port. A slave port is a port that cannot initiate transactions but can respond to transactions initiated by a master port if it determines that it is the targeted component for the initiated transaction.

software application. The software application is the code that runs on the LatticeMico32 microprocessor to control the components, the bus, and the memories. The application is written in a high-level language such as C++.

SPI. SPI is an acronym for serial peripheral interface, a core that allows high-speed synchronous serial data transfers between microprocessors, microcontrollers, and peripheral devices. It can operate either as a master or as a slave.

.v file. A .v file is a Verilog file output by MSB.

watchpoint. A watchpoint is a type of breakpoint that stops the execution of a software program whenever the value of a specific expression changes, without indicating where this may occur. A watchpoint halts program execution, even if the new value being written is the same as the old value of the field.

XML. XML is an abbreviation for Extensible Markup Language, which is a general-purpose markup language used to create special-purpose markup languages for use on the Worldwide Web.

LatticeMico32 Tutorial Recommended References


Recommended ReferencesThe following reference materials are recommended to supplement this tutorial:

Online Help in the LatticeMico32 System graphical user interface, which you can access by choosing Help > Help Contents in the interface.

LatticeMico32 Processor Reference Manual, which contains information on the architecture of the LatticeMico32 microprocessor chip, including configuration options, pipeline architecture, register architecture, debug architecture, and details about the instruction set

LatticeMico32 Development Kit User’s Guide for LatticeECP, which describes how to use the LatticeMico32 Development Kit for LatticeECP devices: how to install all the necessary development tools, set up and connect to the LatticeMico32/DSP development board, use the LatticeMico32 System software (MSB and C/C++ SPE) to create the hardware platform and the software application code that drives it, and download the bitstream to the LatticeMico32 development board

LatticeMico32 Development Kit User’s Guide for LatticeECP2, which describes how to use the LatticeMico32 Development Kit for LatticeECP2 devices: how to install all the necessary development tools, set up and connect to the LatticeMico32/DSP development board, use the LatticeMico32 System software (MSB and C/C++ SPE) to create the hardware platform and the software application code that drives it, and download the bitstream to the LatticeMico32 development board

LatticeMico32 Software Developer User’s Guide, which explains how to use C/C++ SPE to program the microprocessor, gives examples of the code used for different parts of the architecture, and describes the processes occurring in the background

LatticeMico32/DSP Development Board User’s Guide, which describes the features and functionality of the LatticeMico32/DSP development board. This board is designed as a hardware platform for design and development with the LatticeMico32 microprocessor, as well as for the LatticeMico8 microcontroller, and for various DSP functions.

Creating Components in LatticeMico32 System, which describes how to create and add WISHBONE-compatible custom components to the LatticeMico32 System Builder (MSB)

Eclipse C/C++ Development Toolkit User Guide, which is an online manual from Eclipse that gives instructions for using the C/C++ Development Toolkit (CDT) in the Eclipse Workbench

LatticeMico32 Asynchronous SRAM Controller, which describes the features and functionality of the LatticeMico32 asynchronous SRAM controller

LatticeMico32 DMA Controller, which describes the features and functionality of the LatticeMico32 DMA controller

LatticeMico32 On-Chip Memory Controller, which which describes the features and functionality of the LatticeMico32 on-chip memory controller

LatticeMico32 Tutorial Recommended References


LatticeMico32 Parallel Flash Controller, which describes the features and functionality of the LatticeMico32 parallel flash controller

LatticeMico32 GPIO, which describes the features and functionality of the LatticeMico32 GPIO

LatticeMico32 SPI, which describes the features and functionality of the LatticeMico32 serial peripheral interface (SPI)

LatticeMico32 SPI Flash, which describes the features and functionality of the Latticemico32 SPI flash component

LatticeMico32 Timer, which describes the features and functionality of the LatticeMico32 timer

LatticeMico32 UART, which describes the features and functionality of the LatticeMico32 universal asynchronous receiver-transmitter (UART)

Installation Notice, which explains how to install the LatticeMico32 System software

LatticeECP/EC FPGA Family Handbook, which is a collection of the data sheets and application notes on LatticeEC and LatticeECP devices

LatticeECP/EC Family Data Sheet

LatticeECP2 FPGA Family Handbook, which is a collection of the data sheets and application notes on LatticeECP2 devices

LatticeECP2 Family Data Sheet

LatticeECP2M Family Handbook, which is a collection of the data sheets and application notes on LatticeECP2M devices

LatticeECP2M Family Data Sheet

latticemico32 tutorial

Documents

tutorial design

code syntax

software application

microprocessor bitstream

lattice design

microprocessor platform

latticemico32 system

contentslatticemico32