advertisement
Programming Tools User Guide
May 2015
ii
Copyright
Copyright © 2015 Lattice Semiconductor Corporation. All rights reserved. This document may not, in whole or part, be reproduced, modified, distributed, or publicly displayed without prior written consent from Lattice Semiconductor Corporation
(“Lattice”).
Trademarks
All Lattice trademarks are as listed at www.latticesemi.com/legal . Synopsys and
Synplify Pro are trademarks of Synopsys, Inc. Aldec and Active-HDL are trademarks of Aldec, Inc. All other trademarks are the property of their respective owners.
Disclaimers
NO WARRANTIES: THE INFORMATION PROVIDED IN THIS DOCUMENT IS “AS IS”
WITHOUT ANY EXPRESS OR IMPLIED WARRANTY OF ANY KIND INCLUDING
WARRANTIES OF ACCURACY, COMPLETENESS, MERCHANTABILITY,
NONINFRINGEMENT OF INTELLECTUAL PROPERTY, OR FITNESS FOR ANY
PARTICULAR PURPOSE. IN NO EVENT WILL LATTICE OR ITS SUPPLIERS BE
LIABLE FOR ANY DAMAGES WHATSOEVER (WHETHER DIRECT, INDIRECT,
SPECIAL, INCIDENTAL, OR CONSEQUENTIAL, INCLUDING, WITHOUT
LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION, OR
LOSS OF INFORMATION) ARISING OUT OF THE USE OF OR INABILITY TO USE
THE INFORMATION PROVIDED IN THIS DOCUMENT, EVEN IF LATTICE HAS
BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME
JURISDICTIONS PROHIBIT THE EXCLUSION OR LIMITATION OF CERTAIN
LIABILITY, SOME OF THE ABOVE LIMITATIONS MAY NOT APPLY TO YOU.
Lattice may make changes to these materials, specifications, or information, or to the products described herein, at any time without notice. Lattice makes no commitment to update this documentation. Lattice reserves the right to discontinue any product or service without notice and assumes no obligation to correct any errors contained herein or to advise any user of this document of any correction if such be made. Lattice recommends its customers obtain the latest version of the relevant information to establish that the information being relied upon is current and before ordering any products.
Programming Tools User Guide
.
.
.
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
Courier
...
Press the two keys at the same time.
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.
Programming Tools User Guide iii
iv
Programming Tools User Guide
Contents
Programming Tools Description 1
1
2
2
6
6
9
11
11
12
Serial Peripheral Interface Flash
12
Deployment Tool Function Types
15
15
File Conversion Output File Types
16
Embedded System Output File Types
17
External Memory Output File Types
Programming Tools User Guide v
C
ONTENTS
vi
Chapter 4 Embedded Flow Overview 19
30
JTAG Full VME Embedded System Memory
34
JTAG Full VME Embedded Basic Operation
35
JTAG Full VME Embedded Programming Engine
ROM Size Requirement for JTAG Full VME Embedded
JTAG Full VME Embedded Required User Changes
43
51
Converting an SVF File to VME File
Choosing the File-Based or EPROM-Based Version
52
Customizing for the Target Platform
53
EPROM-based JTAG Full VME Embedded User Flow
53
69
JTAG Slim VME Embedded Source Code
Using the PC-based JTAG Slim VME Embedded
75
Using the 8051-based JTAG Slim VME Embedded
80
83
Generating JTAG Slim VME Embedded Files
84
JTAG Slim VME Embedded Source Code
8051 JTAG Slim VME Embedded User Flow
100
Slave SPI Embedded Algorithm Format
Slave SPI Embedded Data Format
Generating Slave SPI Embedded Files
109
Return Codes from Slave SPI Embedded
110
110
MachXO2 or MachXO3L Slave I2C Programming
Programming Tools User Guide
Using the PC-based I2C Embedded Programming
112
Using the 8051-based I2C Programming
113
114
I2C Embedded Programming Required User Changes
116
117
120
121
sysCONFIG Embedded Bitstream Format
122
sysCONFIG Embedded Bitstream Structure
123
sysCONFIG Embedded Basic Operation
124
sysCONFIG Embedded Source Code
125
126
Generating a sysCONFIG Embedded Bitstream
sysCONFIG SPI Port AC Parameters
130
133
C
ONTENTS
Programming Tools User Guide vii
C
ONTENTS
viii
Programming Tools User Guide
Chapter 1
Programming Tools Description
This user guide is intended to provide users with basic information, and references on where to find more detailed information, to assist in configuring and programming Lattice devices using Diamond Programmer and related tools including Deployment Tool, Programming File Utility, Download
Debugger, and Model 300 Programmer.
Programmer
Diamond Programmer is a system for programming devices. The software supports both serial and concurrent (turbo) programming of Lattice devices using PC and Linux environments. The tool also supports embedded microprocessor programming. Refer to
“Programmer Overview” on page 5
.
Deployment Tool
Deployment Tool is a stand-alone tool available from the Diamond
Accessories. The Deployment Tool graphical user interface (GUI) is separate from the Diamond design environment.
The Deployment Tool allows you to generate files for deployment for single devices, a chain of devices, and can also convert data files to other formats and use the data files it produces to generate other data file formats. Refer to
“Deployment Tool Overview” on page 13
.
1
Programming Tools User Guide
2
P
ROGRAMMING
T
OOLS
D
ESCRIPTION
:
Programming File Utility
Programming File Utility
Programming File Utility allows the viewing and editing of different format programming files.The Programming File Utility is a stand-alone tool that allows you to view and compare data files. When comparing two data files, the software generates an output (.out) file with the differences highlighted in red.
Detailed information and procedures on how to use the Programming File
Utility are contained in the “Using Programming File Utility” section of the
Lattice Diamond online help or in the stand-alone Programming File Utility online help.
Download Debugger
Download Debugger is a utility for debugging programming for debugging
Serial Vector Format (SVF) files, Standard Test And Programming Language
(STAPL) files, and Lattice Embedded (VME) files. Download Debugger allows you to program a device, and edit, debug, and trace the process of SVF,
STAPL, and VME files. Download Debugger also allows you to create, edit, or view a VME file in hexadecimal format.
Detailed information and procedures on how to use the Download Debugger are contained in the “Debugging SVF, STAPL, and VME Files” section of the
Lattice Diamond online help or in the stand-alone Download Debugger online help.
Model 300
The Model 300 Programmer is a simple engineering device programmer that allows you to perform single-device programming directly from a PC or Linux environment. The Model 300 Programmer software and hardware support all
JTAG devices produced by Lattice, with device Vcc of 1.8, 2.5, 3.3, and 5.0V.
Detailed information and procedures on how to use the Model 300 hardware and software are contained in the “Using the Model 300 Programmer” section in the Lattice Diamond online help or in the stand-alone Model 300 online help.
Embedded Flow
Programming flow using a processor to read the contents of a stored programming file and programming the FPGA. Lattice provides the option to generate several different file formats for different embedded target options.
Refer to
“Embedded Flow Overview” on page 19
.
Programming Tools User Guide
P
ROGRAMMING
T
OOLS
D
ESCRIPTION
:
Driver Installation
Driver Installation
A utility is available for installing programming drivers after the Diamond or
Programmer software has been installed. Refer to the topic “Installing/
Uninstalling Parallel Port Driver and USB Driver on a PC” in the Lattice
Diamond online help or in the stand-alone Programmer online help.
Programming Tools User Guide
3
P
ROGRAMMING
T
OOLS
D
ESCRIPTION
:
Driver Installation
4
Programming Tools User Guide
Chapter 2
Programmer Overview
Programming Tools User Guide
Diamond Programmer is integrated into the Lattice Diamond software, and is also available as a standalone tool. Both versions come with online help that provides essential information for using the tool to program Lattice devices.
The two versions are virtually identical, except for the following differences:
Integrated Mode
When Programmer is used in integrated mode, it checks that the bitstream (.bit) or JEDEC file (.jed) selected in the Diamond project
(.xcf) matches the file generated by the project. If the file does not match when the file is originally selected, a warning dialog informs the user that the file is not the one generated by the project. If an existing .xcf is opened, and the file is not the correct one generated by the project, the file section for that device is highlighted in red in the Diamond graphical user interface.
Standalone Mode
The stand-alone Programmer supports mature Lattice devices. A “Mature Device” license feature (LSC_PROGRAMMER_MATURE) is required in your license file to enable these devices. Without the license,
Programmer will list the mature devices in the Device Selection and will be able to Scan the devices, but will not be able to program mature devices. The only operation available is Bypass. With the Mature Device license, full support is available.
Diamond Integrated Programmer (Programmer integrated into the Lattice
Diamond software) will list the mature devices in the Device Selection and will be able to Scan the devices, but will not be able to program mature devices, even with the Mature Device license. The only operation available is Bypass.
Full support is only available when running Diamond Programmer as a standalone tool.
5
6
P
ROGRAMMER
O
VERVIEW
:
Usage and flow
Usage and flow
Programming is the process changing the state of a non-volatile programmable element (such as embedded Flash and external SPI Flash devices) by downloading data from JEDEC, bitstream, or hex files transmitted to the download cable through the host computer’s serial communications port; from an embedded system; or from a third party programmer.
Configuring is the process of changing the state of a volatile programmable element (such as SRAM in the FPGA).
Before programming or configuring an FPGA, you need to create and verify your design, and then generate data files. To download a data file into the target device, use the Programmer tool which is integrated into the Diamond software, and also available in a standalone version.
Programmer Design Flow
The design flow for creating and downloading a design chain is the same, whether you select the devices and settings from the software or use an existing chain configuration file.
1. Create a design and compile it to a JEDEC, ISC, hex, or bitstream data file.
2. Using Programmer, create a new chain configuration or open an existing one.
3. Add devices to the chain, and select the data file and operation for each.
4. Arrange the order of the devices in the chain and edit the options for each device as needed.
5. Program the daisy-chained devices using the Program toolbar command.
Figure 1 on page 7 describes the Lattice programming process.
Programming Basics
To successfully program devices in-system, there are a few simple requirements that must first be met. The first of these requirements is that the devices on the board must be correctly connected into an 1149.1 scan chain.
This scan chain can be used for either programming or testing the board.
To program using Programmer a description of the scan chain must be developed. This description, called a chain file, contains basic information about all of the devices in the chain. For the Lattice devices, it includes the device type, the operation to be performed, and the data file, if required by the operation. Additional information in the chain file can include the state of the I/
O pins during programming, along with security requirements. If the chain includes non-Lattice devices, the instruction register length is required for these devices. The instruction register length can be found from the BSDL file or the SVF file for the device.
Programming Tools User Guide
Figure 1: Programming Design Flow
P
ROGRAMMER
O
VERVIEW
:
Usage and flow
Programming Tools User Guide
Another requirement for successful programming is thoughtful board design.
The signals used in a scan chain (TCK, TMS, TDI, and TDO) rarely operate as fast as the data path signals on the board. However, correct board layout methodologies, such as buffering for large chains and termination resistors, are required to ensure trouble-free operation. Some Lattice devices have some additional pins (TRST, ispEN, PROGRAMN, INITN, DONE, SLEEPN, and TOE) that can affect boundary scan programming and test if not taken care of properly.
After all of these requirements have been met, it should be relatively straightforward to program any number of devices on a board. You can
7
8
P
ROGRAMMER
O
VERVIEW
:
Usage and flow program the devices using a PC or Linux system and a board test system connected by one of the following cables:
A Lattice parallel port cable with the 8-pin AMP connector or 10-pin
JEDEC connector
A Lattice USB port cable
In-System Programming
After you have compiled your design to a data file (JEDEC, hex, or bitstream) and device programming is necessary, you must serially shift the fuse map (a fuse map file is a design file that has the fuse data already pre-arranged in exactly the same format as the physical layout of the fuse array of the device) data into the device along with the appropriate addresses and commands.
Lattice non-volatile FPGA devices use embedded flash memory and require only TTL-level programming signals. An integrated state machine controls the sequence of programming operations, such as identifying the device, shifting in the appropriate data and commands, and controlling internal signals to program and erase the embedded Flash in the device. Programming consists of serially shifting the logic implementation stored in a data file into the device along with appropriate addresses and commands, programming the data into the embedded Flash, and shifting the data from the logic array out for device programming verification.
Most of Lattice’s devices use the IEEE 1149.1-1993 Boundary Scan Test
Access Port (TAP) as the primary interface for in-system programming.
Programming Algorithm Basics
Programming a device is similar to programming any piece of memory, such as an EPROM or a Flash memory. The device can be thought of as an array that is programmed one row at a time. The programming information is provided to the software in the form of a data file that must be converted into the row and column fuse map data. Before a non-volatile device can be programmed, it first has to be erased. After the device has been erased, the programming data can be loaded and the device programmed. After the device has been programmed, it will be verified by reading out the data in the device and comparing it to the original.
Figure 2 on page 9 shows the basic programming flow for the device. It does
not include the data file conversion into fuse map data, for it assumes that
Programming Tools User Guide
P
ROGRAMMER
O
VERVIEW
:
Usage and flow step has already been done. This programming flow will be the same, regardless of the programming hardware used.
Figure 2: Basic Device Programming Flow
Note
If the device will not be programmed in-circuit (that is, by a cable or an embedded processor), it is not necessary to preload or save the I/O states.
Programming Tools User Guide
Programming Times
The time it takes to program a device can often determine where in the manufacturing process a device, or group of devices, is programmed. A board test system costing hundreds of thousands of dollars to purchase and as much as one dollar per minute to operate can be an expensive alternative to programming if programming times are too long. In many instances, it is more cost-effective to buy a couple of PCs and program the devices using these much cheaper systems.
The time it takes to completely program a device is based on the time it takes to first erase the device, then to program each row in the device, and finally to
9
P
ROGRAMMER
O
VERVIEW
:
Usage and flow verify the device. The erase time for all devices is between 100 ms and 200 ms. A single row is programmed in 10 ms to 50 ms, depending on the device.
The verification process is the quickest of the required steps in the programming sequence and mainly depends on the time required to shift the verification data out of any given device.
The benefit of minimal programming times is much more obvious on board test systems, because they are included as a part of the test program and are running at the fastest speed possible. Additionally, there is no translation needed to or from the data file, since this has already been done by
Programmer.
USERCODE
User-programmable identification can ease problems associated with document control and device traceability. Every Lattice 1149.1-compliant device contains a 32-bit register that is accessible through the optional IEEE
1149.1 USERCODE instruction. This user-programmable ID register is basically a user’s notepad provided in Flash or SRAM cells on each device.
In the course of system development and production, the proliferation of PLD architectures and patterns can be significant. To further complicate the record-keeping process, design changes often occur, especially in the early stages of product development. The task of maintaining which pattern goes into what device for which socket becomes exceedingly difficult. Once a manufacturing flow has been set, it becomes important to “label” each PLD with pertinent manufacturing information, which is beneficial in the event of a customer problem or return. A USERCODE register is incorporated into devices to store such design and manufacturing data as the manufacturer’s
ID, programming date, programmer make, pattern code, checksum, ISC data file CRC, PCB location, revision number, or product flow. This assists you with the complex chore of record maintenance and product flow control. In practice, the user-programmable USERCODE register can be used for any of a number of ID functions.
Within 32 bits available for data storage, you may find it helpful to define specific fields to make better use of the available storage. A field may use only one bit (or all bits), and can store a wide variety of information. The possibilities for these fields are endless, and their definition is completely up to you.
Even with the device’s security feature enabled, the USERCODE register can still be read. With a pattern code stored in the USERCODE register, you can always identify which pattern has been used in a given device. As a second safety feature, when a device is erased and re-programmed, the USERCODE identification is automatically erased. This feature prevents any situation in which an old USERCODE might be associated with a new pattern.
It is your responsibility to update the USERCODE when reprogramming. The
USERCODE information is not included in the fuse map checksum reading.
10
Programming Tools User Guide
P
ROGRAMMER
O
VERVIEW
:
Usage and flow
Loading the USERCODE instruction makes the USERCODE available to be shifted out in the Shift-DR state of the TAP controller. The USERCODE register can be read while the device is in normal functional operation, allowing the device to be scanned while operating.
Programming Hardware
All programming specifications, such as the programming cycle and data retention, are guaranteed when programming devices over the commercial temperature range (0 to 70 degrees C). It is critical that the programming and bulk erase pulse width specifications are met by the programming platform to ensure proper in-system programming. The details of device programming are invisible to you if you use Lattice programming hardware and software.
Computer Hardware
Programming is most commonly performed on a PC or Linux system using the parallel port cable or the USB port cable.
Parallel Port Cable
The cable uses the parallel port of a PC or Linux system for in-system programming of all Lattice devices. Programmer generates programming signals from the parallel port and passes them through the cable to the JTAG port of the devices. With this cable and a connector on the printed circuit board, no additional components are required to program a device. Refer to the cable data sheet for more detailed specifications and ordering information.
Hardware design considerations for new boards include whether the hardware designer will be using boundary scan test operations or low-voltage
(3.3 V–1.8 V) devices. In a system using 3.3 V devices, the cable version 2.0 should be used. This cable operates with either a 3.3 V or 5 V power source.
In a system using 1.8 V devices, cable version 3.0 must be used. This cable operates with a power of 1.8 V to 5.0 V.
USB Port Cable
The USB port cable uses the USB port of a PC or Linux system for in-system programming of all Lattice devices. Programmer generates programming signals from the USB port and passes them through the USB port cable to the
JTAG, Slave SPI, or I
2
C port of the device.
Programming Tools User Guide
Programming Software
Programmer supports programming of all Lattice devices in a serial daisy chain programming configuration in a PC or Linux environment. The software is built around a graphical user interface. Any required data files are selected by browsing with a built-in file manager. The software supports both serial and
11
P
ROGRAMMER
O
VERVIEW
:
Usage and flow concurrent (turbo) programming of all Lattice devices. Any non-Lattice devices that are compliant with IEEE 1149.1 can be bypassed after their instruction register lengths are defined in the chain description. Any non-
Lattice devices that are compliant with IEEE 1532 can be programmed using an IEEE 1532-compliant BSDL and ISC data file. Programmable devices from other vendors can be programmed through the vendor supplied SVF file.
Embedded Programming
Programmer embedded source code is available for programming devices in an embedded or customized environment. The programming source code is written in ANSI-standard C language, which can be easily incorporated into an embedded system or tester software to support programming of devices.
This code supports such common operations as Erase, Program, Verify, and
Secure. After completion of the logic design and creation of a JEDEC file,
Programmer can create the data files required for in-system programming on customer-specific hardware: PCs, testers, or embedded systems.
FPGA Configuration
Programmer provides efficient and economical alternatives to large and expensive PROMs that are normally used for configuring FPGA devices.
Because SRAM-based FPGA devices are volatile, they require reconfiguration on power cycles. This means that external configuration data must be held in a non-volatile device. On systems that require quick configurations or that do not have processor resources readily available, a dedicated serial PROM can be used. But such a PROM has to be large to accommodate large FPGA devices or multiple devices.
A much easier solution is to use a low-cost, industry-standard flash memory device combined with a LatticeECP/EC, LatticeECP2, LatticeECP3, and
LatticeSCM/SC device.
Serial Peripheral Interface Flash
Programmer, combined with a Lattice cable download, supports the programming of Serial Peripheral Interface (SPI) flash devices.
Several Lattice FPGAs can be configured directly from an external serial peripheral interface (SPI) flash memory devices. Because of their bitstream compression capability, these Lattice FPGAs allow the use of smaller-capacity
SPI memory devices.
For an up-to-date list of Lattice devices that can be configured using SPI flash, as well as a list of supported SPI flash devices, refer to the topic “Serial
Peripheral Interface (SPI) Flash Support” in the Lattice Diamond online help or in the stand-alone Programmer online help.
12
Programming Tools User Guide
Programming Tools User Guide
Chapter 3
Deployment Tool Overview
Deployment Tool is a stand-alone tool available from the Diamond
Accessories and is also available with stand-alone Programmer. The
Deployment Tool graphical user interface (GUI) is separate from the Diamond and stand-alone Programmer design environment.
The Deployment Tool allows you to generate files for deployment for single devices, a chain of devices, and can also convert data files to other formats and use the data files it produces to generate other data file formats. A fourstep wizard allows you to select deployment type, input file type, and output file type.
A basic block diagram of the Deployment Tool flow is shown in Figure 3 on page 14.
13
D
EPLOYMENT
T
OOL
O
VERVIEW
:
Figure 3: Deployment Tool Flow
14
Programming Tools User Guide
D
EPLOYMENT
T
OOL
O
VERVIEW
:
Deployment Tool Function Types
Deployment Tool Function Types
There are four function types available in Deployment Tool:
File Conversion
Tester
Embedded System
External Memory
The function types are accessed from the Function Type dropdown menu on
the Deployment Tool Getting Started dialog box, as shown in Figure 4.
Figure 4: Deployment Tool Function Types
Output File Types
Each function type outputs different file types. This section describes all of the file types that are output by the five function types.
File Conversion Output File Types
The File Conversion function outputs four different file types, as shown in
Figure 5 on page 16. The output types are defined as follows:
IEEE 1532 ISC Data File
Converts JEDEC files to IEEE 1532 compliant
ISC (In System Configuration) data files, which are used in conjunction with
IEEE 1532 compliant BSDL files to program a device.
Application Specific BSDL File
Converts a generic BSDL (Boundary Scan
Description Language) file to an Application Specific BSDL file, using the signal names from the input file (JEDEC or ALT file). Also, for any I/Os that support VREFs or LVDS pairs and are configured as VREFs or LVDS pairs, the application-specific BSDL file changes to accurately reflect the behavior of the VREF or LVDS pair. When generating the Application Specific BSDL file, you have the option to convert bi-directional I/O's to inputs or outputs based
Programming Tools User Guide
15
D
EPLOYMENT
T
OOL
O
VERVIEW
:
Output File Types
Figure 5: File Conversion Output File Types
on your design, or to keep all I/Os as bi-directional. The generic BSDL files are available on the Lattice website.
JEDEC File
Converts the following file types JEDEC, Binary Bitstream,
ASCII Bitstream, or IEEE 1532 ISC into a JEDEC file. The USERCODE,
USERCODE format, and set the Program Security Fuse for the JEDEC file.
Bitstream
Takes a JEDEC, Binary Bitstream, or ASCII Bitstream file and can convert it into the following output formats Binary Bitstream, ASCII
Bitstream, Intel Hex, Motorola Hex, and Extended Tektronix Hex. Users can specify the Program Security Bit, Verify ID Code, Frequency, Compression,
CRC Calculation, USERCODE format, and USERCODE.
Refer to the Deployment Tool online help for information about specific device support.
Tester Output File Types
The Tester function outputs five different file types, as shown in Figure 6.
Figure 6: Tester Output File Types
16
The output types are defined as follows:
Programming Tools User Guide
D
EPLOYMENT
T
OOL
O
VERVIEW
:
Output File Types
SVF - Single Device
SVF Single Takes one of the following user data files types JEDEC, ASCII Bitstream, Binary Bitstream, or IEEE 1532 ISC and then select an operation to generate an SVF (Serial Vector Format) file. Depending on the data file selected then a certain set of operation for the device are available to be selected. The user is able to check several options which will modify the SVF file.
SVF - JTAG Chain
Takes an XCF file generated by Programmer and generates an SVF file. There are several options available that modify the
SVF file including write header and comments, and set maximum data size per row.
STAPL - Single Device
Takes a JEDEC, ASCII Bitstream, Binary
Bitstream, or IEEE 1532 ISC and then depending on the input file type gives a set of available operation that can be performed on the device. A STAPL
(Standard Test And Programming Language) file is generated using the data file and operation.
STAPL - JTAG Chain
Generates a STAPL file for testing using only an XCF file generated by Programmer.
ATE
Takes an XCF file and then the user is able to specify Tester Type, whether or not to skip the verify step in erase program verify or to split into separate files. An ATE (Automated Test Equipment) is a serial vector file specific to a test equipment vendor.
Refer to the Deployment Tool online help for information about specific device support.
Embedded System Output File Types
The Embedded System function outputs five different file types, as shown in
Figure 7: Embedded System Output File Types
Programming Tools User Guide
The output types are defined as follows:
17
D
EPLOYMENT
T
OOL
O
VERVIEW
:
Output File Types
JTAG Full VME Embedded
Takes an XCF as an input file, then the user can check options such as Compress VME, include Header along with several other options. This operation generates a VME file which is a compressed hexadecimal representation of an SVF files.
JTAG Slim VME Embedded
VME is a compressed version of a VME file.
To generate a Slim VME file an XCF file must be specified, then specify whether it is a Compressed VME file and whether or not to generate a HEX file. This operation outputs an algorithm VME file and a data VME file.
Slave SPI Embedded
This file type allows field upgrades via the slave SPI port. This operation can be given an XCF, Binary Bitstream, and ASCII
Bitstream as an input file. If an Bitstream file is given then the operation for the device must be specified along with whether or not to compress the embedded file and whether or not to generate a HEX file. If an XCF file is given there are no other operations or options the user needs to provide. This operation will output an algorithm file (.sea) and a data file (.sed).
I
2
C Embedded
I
2
C embedded files enable field upgrades via the I
2
C port. If an XCF file is specified then the user is given the option to compress the embedded files, generate a hex file, include comments, and if there should be a fixed pulse width. If a Bitstream file is specified then the previous options are available along with selecting the device operation and specifying the length of the I
2
C Slave Address. Two files will be generated a data file (.ied) and an algorithm file (.iea).
sysCONFIG Embedded
Takes an XCF file as input and generates a CPU
(.cpu) file which can be used for field upgrades via the slave parallel or slave serial modes.
Refer to the Deployment Tool online help for information about specific device support.
Also, refer to “Embedded Flow Overview” on page 19
.
18
External Memory Output File Types
The External Memory function outputs four different file types, as shown in
Figure 8 on page 19. The output types are defined as follows:
Hex Conversion
converts a file JEDEC, Binary Bitstream, ASCII Bitstream,
Binary, or Hex to various Hexadecimal file formats which are used to configure the external SPI Flash memory of a device. The output file formats are Intel Hex, Motorola Hex, and Extended Tektronix Hex. The user is also able to set the Program Security bit, Verify ID Code, Frequency, compression,
CRC Calculations and also the Starting Address.
Dual Boot
Takes two JEDEC, Binary Bitstream or ASCII Bitstream files and then creates a single hex file to configure primary and golden sectors of an external SPI Flash. The output format can be Intel Hex, Motorola Hex, and
Extended Tektronix Hex. The device will usually boot form the primary sector unless there is a problem then it will boot from the gold sector.
Programming Tools User Guide
Figure 8: External Memory Output File Types
D
EPLOYMENT
T
OOL
O
VERVIEW
:
Output File Types
Advanced
This operation is for generating hex files which handles more complicated operations such as Multiple Boot, and Quad I/O to configure external memory. Users can set the output hex format, how big the SPI Flash size is, whether or not to do a byte wide bit mirror, retain the bitstream header, and Whether or not to optimize the memory space. Another option is to set multiple user data file and where each of those data file's starting address should be in memory.
sysCONFIG Daisy Chain.
This is used when multiple devices are in a daisy chain and configured from a single SPI flash or CPU. This operation will take two Binary or ASCII bitstreams and convert them into a single hex file.
Refer to the Deployment Tool online help for information about specific device support.
Programming Tools User Guide
19
D
EPLOYMENT
T
OOL
O
VERVIEW
:
Output File Types
20
Programming Tools User Guide
Chapter 4
Embedded Flow Overview
Programming Tools User Guide
Lattice Embedded VME enables in-field upgrades of Lattice programmable devices by suitable embedded processors, and consists of the following:
Enable field upgrades via the JTAG port.
Featured s reduced foot print and is designed for microcontrollers with limited resources, such as 8051 processors.
Enable field upgrades via the slave SPI port.
Enable field upgrades via the I
2
C port.
Enable field upgrades via the slave parallel or slave serial modes.
There are three components to Embedded VME
ANSI C source code, which is shipped with Diamond Programmer. The user compiles this ANSI C Source code into their target system.
Algorithm VME File, which contains the programming algorithm for the target FPGA. The Algorithm VME file is generated using the Deployment
Tool.
Data VME File, which contains the data that will be programmed into the
FPGA. The Data VME file is generated using the Deployment Tool.
For all five embedded types, the Embedded VME support is comprised of C source files that users must port into their embedded systems for the purpose of programming Lattice devices. The porting process is also known as the customization and compiling process. The end product of the porting process will be the Embedded VME in compiled form, which will reside in the embedded systems.
19
E
MBEDDED
F
LOW
O
VERVIEW
:
Depending on the port interface, such as JTAG, SPI, or I
2
C, the user can select one of the five embedded VME types.
Figure 9 shows an example of Full VME embedded file generation for the
JTAG port.
Figure 9: Full Embedded VME Flow
The programming data and programming instructions are compiled into a binary VME file format for the driver to load into the target devices. The VME file can be provided to the driver as a stand-alone file or linked together with the driver.
Figure 10 shows a high-level example of a file-based embedded VME used
for field upgrades.
Figure 10: Example Embedded VME Programming Configuration
20
Programming Tools User Guide
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
Porting of the JTAG VME into Embedded Systems
Porting JTAG Embedded VME is simple and the requirements are very simple to follow:
AC Requirements:
TCK Fmax = 25 MHz.
TCK Rise Time and Fall Time = 50ns maximum.
Delay function resolution and accuracy = 1 millisecond minimum.
DC Requirements:
I/O voltage level of the driver = I/O voltage level of the VCC JTAG port of the target devices. The VCC that power the JTAG port can be:
VCC core (All EE based devices)
VCCIO (MachXO devices)
VCCJ (All SRAM based and Flash based FPGA devices)
Programming current = 1 Ampere maximum.
JTAG Programmability of Lattice Devices
Lattice's devices can be classified into three groups based on programmability:
SRAM based only devices (volatile devices).
EE based devices (non-volatile devices).
Flash based devices (non-volatile devices).
Note
For information on configuring the Lattice iCE40 family of devices from an embedded processor, refer to TN1248 , iCE40 Programming and Configuration
Guide.
The SRAM based only devices are the easiest devices to support in terms of
Embedded VME porting for they normally do not require accurate timing.
The EE based devices are much more challenging for they require the 1 millisecond resolution and accurate timing.
The Flash based devices are the most challenging among the three types.
The delay function not only must have the 1 millisecond resolution and accuracy, it also must be able to provide the cumulative delay time up to 150 seconds – the worst case erase time of some Flash based devices.
The EE based devices are supported by the programming flow generally referred to as the fixed pulse width flow. The Flash based devices require the
21
E
MBEDDED
F
LOW
O
VERVIEW
:
Figure 11: ispMACH4000 Fixed Delay Time Programming Flow
22
looping programming flow. The most critical requirement to ensure the devices are programmed reliably rests on the accuracy of the delay function.
If the devices are not given the required programming delay time, the Flash based devices will fail the verification during programming. It will be worse if failure happens during Flash erase.
When the erase operation is terminated before completion due to insufficient delay time, the Flash will have an unknown pattern residing in it which might cause the device entering the contentious state. When the device is in contentious state, it will be very hot and would not respond to further programming commands. EE based devices may not fail verification but they will fail to meet the 10 year data retention as specified.
All Lattice EE and Flash based devices are designed with the over-stress and over-charge protection technology. This technology is very critical to the superior In-System Programmability of Lattice’s non-volatile devices. The devices cannot be damaged when given an erase delay time or programming delay time longer than the minimum specified.
The accuracy of the delay function discussed in this document will focus only on meeting the minimum requirement. It means that when the delay function is called to generate, for example, 100 ms delay time (by calling the delay
Programming Tools User Guide
Figure 12: MachXO Looping Programming Flow
E
MBEDDED
F
LOW
O
VERVIEW
:
Programming Tools User Guide
function 100 times), as long as the resulting delay time is equal to or greater than 100 ms, the delay time is considered accurate.
The only undesirable side effect of applying longer erase delay time or programming delay time to the devices is on the programming throughput.
Diamond Programmer provides precise delay timing to meet the programming specification and optimizing on throughput.
The Deployment Tool software will automatically determine whether the device requires the fixed delay time programming flow or the looping programming flow when generating the VME file. Also, the device specific programming algorithm details, such as row size, the maximum loop count, and the delay required per each loop, are all embedded into the VME file automatically.
23
E
MBEDDED
F
LOW
O
VERVIEW
:
If interested to find out the details of their VME files, simply convert the binary
VME files into the corresponding text based SVF file format using the
Download Debugger shipped with Diamond Programmer.
The verify flow is identical for the looping and fixed pulse programming flow.
The delay required for the verify flow is usually ~100us per row. The VME file still requires 1 millisecond delay per row since the PC cannot provide accurate timing if the delay is less than 1 millisecond.
Thus, the only Embedded VME implementation challenge is the development of an accurate delay function to provide 1 millisecond minimum delay time.
Embedded VME Porting Detail
Step 1: Customize JTAG Embedded VME by modifying hardware.c
Figure 13: Map Four GPIO Pins from the CPU to the Four JTAG Pins
The pin mapping index table on the hardware.c must be revised to match with the customer’s board layout. On the PCB that is the target for porting the
Embedded VME, it is important and a good practice to route the JTAG port to a test header for easy access using an oscilloscope or connecting to
Programmer for debugging.
24
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
All VME files begin with IDCODE verification to ensure the JTAG port pins are mapped and connected properly.
Programming Tools User Guide
Modify the Delay Function
When porting Embedded VME to a native CPU environment, the speed of the
CPU or the system clock that drives the CPU is usually known. The speed or the time it takes for the native CPU to execute one loop then can be calculated.
The for loop usually is compiled into the ASSEMBLY code as shown below:
LOOP: EDC RA;
JNZ LOOP;
If each line of assembly code needs four (4) machine cycles to execute, the total number of machine cycles to execute the loop is 2 x 4 = 8.
Usually: system clock = machine clock (the internal CPU clock).
Note
Some CPUs have a clock multiplier to double the system clock for the machine clock.
Let the machine clock frequency of the CPU be F (in MHz), then one machine cycle = 1/F.
The time it takes to execute one loop = (1/F) x 8.
It is obvious that the formula can be transposed into one microsecond = F/8.
Example: The CPU internal clock is set to 48 MHz, then one microsecond =
48/8 = 6.
25
E
MBEDDED
F
LOW
O
VERVIEW
:
The C code shown below can be used to create the millisecond accuracy. All that needs to be changed is the CPU speed.
26
Step 2: Calibration
It is important to confirm if the delay function is indeed providing the accuracy required. It is also important to confirm the TCK frequency. As an example, we will estimate the minimum system clock frequency of the native CPU that does not require the TCK to be slowed down. The TCK could be generated by the following code.
writePort (g_ucPinTCK, 0x00); writePort (g_ucPinTCK, 0x01);
Let the number of system clocks to execute one line of code = 8 clocks.
The total number of clock for one pulse = 2 x 8 = 16.
The total amount of time for one pulse = 1/F x 16.
Lattice devices TCK frequency max = 25 MHz.
The equation becomes: 1/25 = 1/F x 16.
The maximum frequency of the CPU: F = 16 x 25 = 400 MHz.
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
If the system clock of the native CPU is faster than 400 MHz, the TCK pulses must be slowed down to meet the 25 MHz maximum specification.
The setup time and hold time of TDI, TMS, and TDO relative to TCK is not of concern for Embedded VME is constructed in the fashion that it is not possible to violate that requirement whenever the frequency of TCK is within the specification.
Figure 14: JTAG Embedded VME Delay Calibration
The calibrate function in Embedded VME can be launched by using the –c switch to cause the waveform as follow captured on the scope with the probe attached to the TCK wire.
If the pulse width is found to be smaller than 1 millisecond, then increase the cpu_frequency value until 1 millisecond delay is captured by the calibration function.
If the TCK frequency is found to be faster than 25 MHz, then change the sclock() function in hardware.c as shown below. The IdleTime normally is
Programming Tools User Guide
27
E
MBEDDED
F
LOW
O
VERVIEW
:
Figure 15: JTAG Embedded VME Delay Calibration TCK Waveforms
28
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
initialized to 0. If it is initialized to 1, then the TCK frequency is effectively reduced by half. Use this technique to reduce the TCK frequency until meeting the specification.
Programming Tools User Guide
Step 3: Program Devices
Once the calibration is done, the Embedded VME (actually the JTAG port driver) is ready to program the devices. The device specific programming information is all self-contained in the VME file.
The VME file actually has six major sections:
1. Check the IDCODE,
2. Erase the device,
3. Program the device,
4. Verify the device,
5. Program the done fuse,
6. Wake-up the device.
IDCODE check failure is the most common failure when porting Embedded
VME. It is a good practice to generate a Verify IDCODE only VME file first.
Run the VME file. If it passes, then the JTAG port to GPIO mapping is confirmed. Once the port mapping is confirmed, then the programming VME file can be used.
Accurate timing is very critical to program devices reliably.
Using the calibration routine provided by Embedded VME will achieve the accurate timing.
29
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
JTAG Full VME Embedded
The JTAG Full VME Embedded VME software brings programming software to embedded applications. Using Lattice Semiconductor’s Diamond
Programmer and Deployment Tools, you are provided with all necessary capabilities for programming devices in a single or multiple device chain.
Developed to solve many programming issues facing today’s PLD users,
JTAG Full VME Embedded provides advanced features including fast programming times, and small file sizes.
The JTAG Full VME Embedded software is a simplified version of the full
Diamond Programmer. By making it serial vector format (SVF) file centric,
JTAG Full VME Embedded is better targeted for embedded systems. Lattice
JTAG devices are supported and users are able to program competitor devices through a simple SVF file translator. Lattice JTAG devices are those devices that can be programmed using the IEEE 1149.1 boundary scan TAP controller interface. Users are able to quickly and efficiently program chains of devices using this powerful utility, thus improving productivity and lowering costs.
An advantage of JTAG Full VME Embedded over vendor or architecturespecific methods is that once it is developed, it supports all present and future devices. As long as the programming flow can be described as an SVF file, the main engine does not have to change. For embedded environments, it is important to have deterministic memory requirements. By pre-processing the
SVF file, it is possible to know the exact resources required to implement the programming algorithm and to store the programming data. The nature of the
SVF file also allows the resources available to determine how the file is processed. Large shift instructions can be broken into multiple instructions if the embedded system does not have enough RAM available to store the entire row in one pass. Since the SVF file is serial in nature, it can be segmented to fit available RAM, PROM or FLASH memory.
The JTAG Full VME Embedded source code is designed to be hardware and platform independent. A VME data file, or VME file, runs on all JTAG Full VME
Embedded applications.
See Also
JTAG Full VME Embedded Basic Operation
30
VME File Format
A VME file is simply an SVF file that has been compressed. SVF file includes algorithm and data file in ASCII format, and VME file is the SVF file in the optimized binary format. Compared with SVF file, VME files require minimized memory space to store the bitstream file and has optimized code size. SVF keywords such as SIR and SDR are replaced with the byte codes 0x11 and
0x12, respectively. This reduces the VME file by writing only one byte of data, the byte codes, instead of writing the entire SVF keyword, which would use more characters.
JTAG Full VME Embedded file supports compression to reduce the VME file size by compressing the data and address streams. A looping compression is
Programming Tools User Guide
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded also employed to reduce the file size even further by taking advantage of the repeating SVF constructs. The following describes each compression scheme.
Compressed VME Files
The compression scheme is applied to the address and data stream following SIR and SDR, respectively. These streams will try to be compressed by 0x00, 0xFF, or by 4-bit count.
For example, consider the following line in a SVF file:
SDR 102 TDI (20000000000000000000000000);
The address stream is ‘20000000000000000000000000’. The repeating zeros in the stream can be easily compressed by 0x00. Compression with
0xFF works in the same manner, except that instead of the data stream containing zeros, it would contain ‘F’s.
Compression by 4-bit count works by looking for repeating patterns within the data stream that are not zeros or ‘F’s.
For example, consider the following line in a SVF file:
SDR 80 TDI (7F97F97F97F97F97F97F9);
The repeating 4-bit count in this example would be ‘7F9,’ because it repeats throughout the data stream. The 4-bit would be written only once in the VME file, and would be followed by the number of repetitions found within the data stream.
The compression scheme reduces the file size by not extrapolating repeating information within the address and data streams. That task is left for the VME processor.
Looping VME Files
In an SVF file, repeating constructs can be observed.
The looping scheme takes advantage of these constructs by creating a template with the repeating information, and the differentiating date is replaced by a placeholder. The differentiating data will be written after the construct.
For example, the following data is found in a SVF file:
SIR 5 TDI (01);
SDR 102 TDI (20000000000000000000000000);
SIR 5 TDI (02);
SDR 80 TDI (7BFFF7BFFFF7BFFF7BFF);
SIR 5 TDI (07);
RUNTEST IDLE 3 TCK 1.20E-002 SEC;
SIR 5 TDI (01);
31
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
SDR 102 TDI (10000000000000000000000000);
SIR 5 TDI (02);
SDR 80 TDI (FFFF7FFFFFFFFFFFFFFF);
SIR 5 TDI (07);
RUNTEST IDLE 3 TCK 1.20E-002 SEC;
SIR 5 TDI (01);
SDR 102 TDI (08000000000000000000000000);
SIR 5 TDI (02);
SDR 80 TDI (FFFFFFFFFFFFFFFFFFFF);
SIR 5 TDI (07);
RUNTEST IDLE 3 TCK 1.20E-002 SEC;
...
...
The looping template is built based on the repeating SIR lines. Notice how the
TDI values for the SIR commands are a repeating sequence of 01, 02, and
07. In this case the resulting template would be:
SIR 5 TDI (01);
SDR 102 TDI VAR;
SIR 5 TDI (02);
SDR 80 TDI VAR;
SIR 5 TDI (07);
RUNTEST IDLE 3 TCK 1.20E-002 SEC;
VAR is written in place to hold the data that does not repeat. The nonrepeating data will get written into the VME file following each template. The example above would look like this in the VME file:
LOOP 3
SIR 5 TDI (01);
SDR 102 TDI VAR;
SIR 5 TDI (02);
32
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
SDR 80 TDI VAR;
SIR 5 TDI (07);
RUNTEST IDLE 3 TCK 1.20E-002 SEC;
ENDLOOP
(20000000000000000000000000)
(7BFFF7BFFFF7BFFF7BFF)
(10000000000000000000000000)
(FFFF7FFFFFFFFFFFFFFF)
(08000000000000000000000000)
(FFFFFFFFFFFFFFFFFFFF)
The ‘LOOP 3’ tells the VME processor to loop the template three times. Each time it encounters a ‘VAR’, it will grab the first available line of data following the ‘ENDLOOP’ and replace ‘VAR’ with it. This technique reduces the file significantly by keeping the similar constructs to a minimal, and only writing the differences.
JTAG Full VME Embedded Flow
The JTAG Full VME Embedded System allows you to program a device using the microprocessor in an embedded system. When you install the VM software, a separate VMEmbedded folder containing the VME source code and executables is installed on your hard drive. Compiling the VME source code gives you an executable file that you can store in your system’s memory for programming using the JTAG port.
The following figure illustrates the JTAG Full VME Embedded flow.
Programming Tools User Guide
See Also
33
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
JTAG Full VME Embedded System
Memory
The following figure illustrates JTAG Full VME Embedded system memory.
34
See Also
JTAG Full VME Embedded Basic Operation
JTAG Full VME Embedded Basic
Operation
There are three modes of JTAG Full VME Embedded operation.
File Mode
Under the file mode, data is stored in a file system such as a hard drive or a DOS flash. The data file is accessed using C library calls, such as fopen, fread, and fclose. The file read operations collect data into the system memory. The system memory of the Embedded system must be able to store the entire bitstream from the file in a contiguous block of memory. The memory block can be allocated in one of the three locations.
Data Segment – You can pre-determine how many bytes of data the bitstream will require and then create an uninitialized array variable to hold the data. This permanently allocates a portion of the Data Segment.
For example: char programmingData[0x10000]; // allocate 64K
Stack Segment – You can pre-determine how many bytes of data the bitstream will require and then create an uninitialized array variable to
Programming Tools User Guide
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded hold the data. Depending upon the function call sequence, this may or may not permanently allocate a portion of the system memory. See the example code below.
int MyFunction ( ) { char bitstreamArray[0x10000];
}
Heap Segment – You can determine at runtime how many bytes of data the bitstream will require and then dynamically allocate an uninitialized array variable to hold the data. You are responsible for freeing the memory when it is not being used any longer. Below is an example.
char *bitstreamData; bitstreamData = (char *)malloc(numberOfBitstreamBytes);
Static Linking Mode
Under the static linking mode, the bitstream data is converted from the file on the hard drive into a C source code file. The C source code defines a byte array. The byte array is exactly the size of the bitstream. The byte array can be linked into either the Code Segment or the
Data Segment. The memory allocated for the bitstream is permanently consumed.
PROM Mode
Under the PROM-based mode, the bitstream file is converted from the file on the hard drive into an Intel HEX file. The HEX file is loaded into a non-volatile memory using a PROM programming tool. The HEX file data is placed in the non-volatile memory at a known address (that is, a fixed address). The user C code initializes a pointer. The pointer is given the starting address of the HEX byte stream. The memory used by the bitstream is permanently allocated in the non-volatile memory.
See Also
JTAG Full VME Embedded System Memory
VME Source Code
The JTAG Full VME Embedded source code is written in standard ANSI C and is simplified with embedded applications in mind. Most embedded applications have greater limits on program and data sizes than PC or workstation applications. The areas most likely to differ between platforms are the timing delay function and hardware port manipulation.
The current version of the JTAG Full VME Embedded software is available through the Programmer installation. The installation creates a sub-directory called VMEmbedded, where the pre-compiled executables, source code, and readme.txt can be found.
There are four sets of embedded-related source code that are shipped with
Programmer.
VME – The file-based VME is the programming engine that accepts VME files as command line arguments to process the devices. By default, the executable compiled from this source code targets Windows operating
35
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
systems. You can make small modifications to make the compiled executable accommodate other platforms.
VME_eprom – The PROM-based VME is the programming engine that requires compiling a HEX file, which is a C-programming file, with the source code to create an executable engine that can be embedded onto the embedded system.
svf2vme – The svf2vme is a command line utility that can convert SVF files into VME files.
vme2hex – The vme2hex is a command line utility that can convert VME files into HEX files.
Among all the source codes, only the hardware.c file
You should customize the hardware.c file according to your target platform.
JTAG Full VME Embedded
Programming Engine
The programming engine of the JTAG Full VME Embedded software is driven by the byte codes of the VME format file. It manipulates the I/O ports and sends commands to the customer firmware. The commands sent from the programming engine requires the I/O system to be connected to the device's
JTAG port. The VME byte codes instruct the engine as to what sequence of functions to follow in order to shift in instructions, move the TAP controller state machine, shift data in and out of the device, and observe delay. The engine has the following three layers.
User interface layer (ispvm_ui.c) – Directs inputs and outputs.
Processor layer (ivm_core.c) – Decodes commands, checks CRC prior to processing, and does optional decompression.
Physical layer (hardware.c) – Shifts data to target device. This is the only
file that you need to edit. See Customizing for the Target Platform for
details.
36
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
The following figure illustrates JTAG Full VME Embedded JTAG port programming engine.
Programming Tools User Guide
RAM Size Requirement for VME
To calculate the worst-case size of memory needed to program a device, in terms of bytes, locate the size of the largest register in the device. This is usually the data shift register. Divide that number by eight, and then multiply the quotient by two: one for TDI and one for TDO. If the device has MASK, multiply the quotient by three instead of two.
This method only calculates the RAM requirements for the data of the device.
It does not account for transient variables that are used to execute the programming algorithm. Transient variables are more difficult to calculate because they appear in and out of scope often. Also, a variable size may depend on the microprocessor’s register size. For example, an integer variable on a 32-bit system is four bytes while the same variable on a 16-bit system is only two bytes.
To approximate the RAM requirement for the run-time variables, add twenty percent to the required RAM.
37
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
SIR
SDR
SIR
SDR
SIR
SDR
6
80
6
202
6
202
RAM Calculation Example
The following is a partial SVF for the M4A3 32/
32 device:
TDI
TDI
TDI
TDI
TDI
TDI
TDO
MASK
(03);
(00000000000000000040);
(04);
(200000000000000000000000000000000000000000000000000);
(07);
(200000000000000000000000000000000000000000000000000)
(000410410410410410410410410104104104104104104104104)
(210410410410410410410410410104104104104104104104104);
The largest data frame size in this device is 202 bits. Therefore, TDI, TDO, and MASK each require 26 bytes, making it a total of 3*26 = 78 bytes. To account for run-time variables, the total required size would be 78 * 1.2 = 94 bytes.
To verify that the calculation is correct, convert the SVF file to VME, and use the VME2HEX utility to convert from VME to HEX. This utility generates the vme_file.h file, which gives the definitive memory size requirement.
The variables that are of concern to memory are:
MaskBuf
TdiBuf
TdoBuf
HdrBuf
TdrBuf
HirBuf
TirBuf
HeapBuf
CRCBuf
CMASKBuf
As expected, MaskBuf, TdiBuf, and TDOBuf each requires 26 bytes. If the device were in a chain, HdrBuf (Header Data Register), TdrBuf (Trailer Data
Register), HirBuf (Header Instruction Register), and TriBuf (Trailer Instruction
Register) would need extra bytes.
If the VME file had been generated with the looping option, HeapBuf would require extra bytes as well. Looping requires slightly more RAM but significantly less ROM. When the VME file has not been looped, it does not require any additional RAM, but ROM size can significantly increase. This
38
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded trade-off is file-dependent.If the original SVF were 1532-compliant, CRCBuf and CMASKBuf would require extra bytes as well.
ROM Size Requirement for JTAG Full
VME Embedded
To calculate the worst-case ROM size for a given device, multiply the number of frames by the frame size. Divide that number by eight to obtain the required
ROM size, in terms of bytes.
This method assumes that the SVF file will be generated with the turbo option.
If the SVF file were generated with the sequential option, the worst-case ROM size would be doubled.
This method only calculates the ROM requirements for the data. It does not account for opcodes that are used to translate the algorithm of the device. To approximate the ROM requirement for the algorithm opcodes, add twenty percent to the required ROM.
The actual ROM requirement might be significantly less than the theoretical worst-case requirement because SVF2VME utilizes two compression techniques, compression and looping, to decrease the VME file. The file size difference is file-dependent.
ROM Size Calculation Example
The following example calculates the worst-case ROM size for the device LC4128:
Frame size = 740 x Number of frames = 100
____________________________
Data ROM size = 74000 bits
Data ROM size = 74000 x 1.2
____________________________
Overall ROM size = 88800 bits
Programming Tools User Guide
JTAG Full VME Embedded Required
User Changes
To make the JTAG Full VME Embedded or JTAG Slim VME Embedded software work on your target system, you need to modify the following C functions in the hardware.c source code.
Timer
The engine requires the ability to delay for fixed time periods. The minimum granularity of the delay is 1 microsecond. You can determine the type of delay. This can be a simple software timing loop, a hardware timer, or an operating system call, for example, sleep().
Port Initialization
The firmware needs to place the port I/O into a known state. The software assumes this has occurred.
39
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Get Data Byte
The engine calls the GetByte() function to collect one byte from the JTAG Full VME Embedded or CPU bytestream.
Modify Port Register
The engine, as it parses the bitstream data, changes an in-memory copy of the data to be written onto the I/O pins. Calls to this function do not modify the I/O pins. The engine uses virtual types (for example, DONE_PIN) which this function turns into physical I/O pin locations
(for example, 0x400).
Output Data Byte
The engine calls this function to write the in-memory copy onto the I/O pins.
Input Status
This function is used by the engine to read back programming status information. The function translates physical pin locations (for example,
0x400) into virtual types used by the engine (for example, DONE_PIN).
Output Configuration Pins
Some systems may wish to use the FPGA
CFG pins, and have the Embedded system control them. There is a separate function call to manipulate the CFG pins.
Bitstream Initialization
You must determine how you plan to get the bitstream into your memory system, pre-compiled, HEX file based, or dynamically installed. Whichever method you use the data structures which pin to the bitstream need to be initialized prior to the first GetByte function call.
See Also
Customizing for the Target Platform
JTAG Slim VME Embedded Source Code
40
Programming Tools User Guide
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Program Memory Requirement
The following figure illustrates the JTAG Full VME Embedded program memory requirement.
Program Memory Allocation
The following figure illustrates the JTAG Full VME Embedded program memory allocation.
41
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
File Based
(Bitstream File External)
PROM Based
(Bitstream File Integrated)
Sample Program Size
This page provides sample program size for JTAG Full VME Embedded,
JTAG Slim VME Embedded, and sysCONFIG Embedded.
JTAG Port
JTAG Full VME
Embedded
JTAG Slim
VME
Embedded
8-Bit 32-Bit
52KB
16-Bit
21KB 4.2KB
non-JTAG Port sysCONFIG
Embedded
32-Bit
48KB
16-Bit
19KB
Total
As Shown
52KB 21KB 4.2KB
48KB 19KB As Shown +
VME File Size
.
42
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Device
LC4032V/B/C/ZC
LA4032V/ZC
LC4064V/B/C/ZC-32IO
LA4064V/ZC-32IO
LC4064V/B/C/ZC
LA4064V/ZC
LC4128V/B/C/ZC
LA4128V/ZC
LC4256V/B/C/ZC
LC4256V/B/C-160IO
LC4384V/B/C
LC4512V/B/C
LC4032ZE
LC4064ZE
VME File Size
The following table compares VME file sizes taking typical Lattice devices for examples.
Device Row Size
(Bits)
Data File Size
ispMACH 4000
Programming Mode: Turbo
Operation: Erase, Program, Verify
172
352
1KB
3KB
1KB
4KB
356
JTAG Slim VME
Embedded File Size
No Compression
(1K Byte = 1024 Bytes)
Algorithm File Size
VME File Size
No Compression
(1K Byte = 1024 Bytes)
8KB
12KB
13KB
740
1592
1624
1KB
5KB
1KB
10KB
1KB
19KB
1KB
20KB
22KB
41KB
43KB
65KB 2616
3632
1KB
31KB
1KB
43KB
ispMACH 4000ZE
Programming Mode: Turbo
Operation: Erase, Program, Verify
172 1KB
356
3KB
1KB
5KB
89KB
8KB
13KB
Programming Tools User Guide
43
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Device
44
LC4128ZE
LC4256ZE ispPAC-POWR607 ispPAC-POWR6AT6 ispPAC-POWR1014/14A ispPAC-POWR1220AT8/2
LFEC/ECP-1E
LFEC/ECP-3E
LFEC/ECP-6E
LFEC/ECP-10E
LFEC/ECP-15E
LFEC/ECP-20E
Device Row Size
(Bits)
JTAG Slim VME
Embedded File Size
No Compression
(1K Byte = 1024 Bytes)
Algorithm File Size
VME File Size
No Compression
(1K Byte = 1024 Bytes)
740
56
Data File Size
1KB
10KB
1KB 1592
19KB
ispPAC Power Manager II
Programming Mode: Sequential
Operation: Erase, Program, Verify
81 1KB
2KB
1KB
1KB
22KB
41KB
9KB
1KB
18KB 123
243
1KB
6KB
1KB
13KB
LatticeEC/ECP
Programming Mode: Sequential
Operation: Fast Program
470 1KB
558
754
1094
1270
1358
75KB
1KB
125KB
1KB
216KB
1KB
378KB
1KB
518KB
1KB
641KB
39KB
75KB
126KB
217KB
379KB
519KB
642KB
Programming Tools User Guide
Device
LFEC/ECP-33E
LFXP3C/E
LFXP6C/E
LFXP10C/E
LFXP15C/E
LFXP20C/E
LCMXO256C/E
LCMXO640C/E
LCMXO1200C/E
LCMXO2280C/E
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Device Row Size
(Bits)
1798
957KB
LatticeXP
Programming Mode: Sequential
Operation: FLASH Erase, Program, Verify
558
734
JTAG Slim VME
Embedded File Size
No Compression
(1K Byte = 1024 Bytes)
Algorithm File Size
Data File Size
1KB
VME File Size
No Compression
(1K Byte = 1024 Bytes)
958KB
1KB
117KB
1KB
189KB
437KB
673KB
2148
2500
1KB
340KB
1KB
494KB
1087KB
1565KB
1930KB 2676 1KB
611KB
MachXO
Programming Mode: Sequential
Operation: FLASH Erase, Program, Verify
192 1KB
320 (used BSCAN
Length)
424 (used BSCAN
Length)
544 (used BSCAN
Length)
8KB
1KB
17KB
1KB
35KB
1KB
62KB
36KB
70KB
111KB
195KB
Programming Tools User Guide
45
LCMXO2-256ZE
LCMXO2-256HC
LCMXO2-640ZE
LCMXO2-640HC
LCMXO2-1200ZE
LCMXO2-1200HC
LCMXO2-640UHC
LCMXO2-2000ZE
LCMXO2-2000HC
LCMXO2-1200UHC
LCMXO2-2000HE
LCMXO2-4000ZE
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Device Device Row Size
(Bits)
JTAG Slim VME
Embedded File Size
No Compression
(1K Byte = 1024 Bytes)
Algorithm File Size
VME File Size
No Compression
(1K Byte = 1024 Bytes)
Data File Size
MachXO2
Programming Mode: Sequential
Operation: FLASH Erase, Program, Verify
504 42KB
504
888
888
1080
1080
1080
1272
1272
1272
1272
1560
33KB
48KB
33KB
48KB
33KB
48KB
41KB
68KB
1KB
11KB
1KB
11KB
13KB
24KB
13KB
24KB
41KB
68KB
41KB
68KB
41KB
68KB
49KB
115KB
42KB
89KB
89KB
172KB
172KB
172KB
243KB
243KB
243KB
243KB
409KB
46
Programming Tools User Guide
Device
LCMXO2-4000HC
LCMXO2-2000UHC
LCMXO2-4000HE
LCMXO2-2000UHE
LCMXO2-7000ZE
LCMXO2-7000HE
LCMXO2-7000HC
LCMXO3L-2100C
LCMXO3L-4300C
LCMXO3L-6900C
LPTM20
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Device Row Size
(Bits)
1560
JTAG Slim VME
Embedded File Size
No Compression
(1K Byte = 1024 Bytes)
Algorithm File Size
Data File Size
49KB
VME File Size
No Compression
(1K Byte = 1024 Bytes)
409KB
1560
1560
1560
1992
1992
198KB
127KB
198KB
127KB 1992
198KB
MachXO3L
Programming Mode: Sequential
Operation: FLASH Erase, Program, Verify
115KB
49KB
115KB
49KB
115KB
49KB
115KB
127KB
409KB
409KB
409KB
700KB
700KB
700KB
243KB 1272
1560
41KB
68KB
49KB
115KB
1992 127KB
198KB
Platform Manager 2
Programming Mode: Sequential
Operation: FLASH Erase, Program, Verify
888 20KB
14KB
409KB
94KB
47
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Device
48
LPTM21
LFE2-6E/SE
LFE2-12E/SE
LFE2-20E/SE
LFE2-35E/SE
LFE2-50E/SE
LFE2-70E/SE
LFE2M20E/SE
LFE2M35E/SE
LFE2M50E/SE
LFE2M70E/SE
LFE2M100E/SE
Device Row Size
(Bits)
1080
LatticeECP2/2S
Programming Mode: Sequential
Operation: Fast Program
22KB
752
752
JTAG Slim VME
Embedded File Size
No Compression
(1K Byte = 1024 Bytes)
Algorithm File Size
Data File Size
40KB
VME File Size
No Compression
(1K Byte = 1024 Bytes)
158KB
1KB
190KB
1KB
364KB
191KB
365KB
566KB 1018
1284
1643
2032
1KB
565KB
1KB
800KB
1KB
1140KB
1KB
1700KB
LatticeECP2M/2MS
Programming Mode: Sequential
Operation: Fast Program
1615 1KB
802KB
1141KB
1702KB
758KB
2042
2419
2799
3120
756KB
1KB
1258KB
1KB
2022KB
1KB
2535KB
1KB
3281KB
1259KB
2023KB
2537KB
3282KB
Programming Tools User Guide
Device
LFXP2-5E
LFXP2-8E
LFXP2-17E
LFXP2-30E
LFXP2-40E
LFE3-17E/EA
LFE3-35E/EA
LFE3-70E/EA
LFE3-95E/EA
LFE3-150E/EA
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Device Row Size
(Bits)
Data File Size
LatticeXP2
Programming Mode: Sequential
Operation: FLASH Erase, Program, Verify
638
772
1KB
154KB
1KB
243KB
2188
2644
JTAG Slim VME
Embedded File Size
No Compression
(1K Byte = 1024 Bytes)
Algorithm File Size
VME File Size
No Compression
(1K Byte = 1024 Bytes)
1KB
446KB
1KB
731KB
561KB
859KB
1423KB
2308KB
3176KB 3384 1KB
1017KB
LatticeECP3
Programming Mode: Sequential
Operation: Fast Program
2584 1KB
3416
6724
503KB
1KB
882KB
1KB
505KB
883KB
2336KB
6724
2333KB
1KB
2333KB
1KB 8380
3714KB
ECP5U
Programming Mode: Sequential
Operation: Fast Program
2336KB
3719KB
Programming Tools User Guide
49
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Device
LFE5U-85F
LFE5UM85F
LFSC3GA15E
LFSCM3GA15E
LFSC3GA25E
LFSCM3GA25E
LFSC3GA40E
LFSCM3GA40E
LFSC3GA80E
LFSCM3GA80E
LFSC3GA115E
LFSCM3GA115E
Device Row Size
(Bits)
JTAG Slim VME
Embedded File Size
No Compression
(1K Byte = 1024 Bytes)
Algorithm File Size
Data File Size
1KB
VME File Size
No Compression
(1K Byte = 1024 Bytes)
85KB 1136
1883KB
ECP5UM
Programming Mode: Sequential
Operation: Fast Program
1136 1KB
1883KB
85KB
LatticeSC/SCM
Programming Mode: Sequential
Operation: Fast Program
1043 1KB
1316
1652
542KB
1KB
700KB
1KB
2156
2639
1076KB
1KB
2719KB
1KB
3084KB
543KB
701KB
1078KB
2723KB
3088KB
Important!
If the VME file size is more than 64K bytes, the VME Embedded driver must be compiled as a 32-bit program. A 16-bit program can only address up to 64K bytes of memory maximum.
50
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Using JTAG Full VME Embedded
The procedure of generating and processing the VME can be done by using the Programmer graphical user interface.
Table 1: JTAG Full VME Program Descriptions
Program Description
JTAG Full VME Embedded
(file-based)
The file-based JTAG Full VME Embedded is the programming engine that accepts VME files as command line arguments to process the device(s).
JTAG Full VME Embedded
(EPROM-based)
The EPROM-based JTAG Full VME Embedded is the programming engine that requires compiling a HEX file, which is a C-programming file, with the source code to create an executable engine that can be embedded onto the embedded system.
svf2vme vme2hex
The svf2vme is a command line utility that can convert
SVF files into VME files.
The vme2hex is a command line utility that can convert
VME files into HEX files.
Programming Tools User Guide
Generating VME Files
A VME file is a variation of an SVF file that has been compressed into a binary file. It allows you to program a device from the microprocessor on your printed circuit board. The VME files can be created in Deployment Tool by selecting
Lattice Programmer-generated an XCF file. An XCF file is a configuration file used by Diamond Programmer and for programming devices in a JTAG daisy chain. The XCF file contains information about each device, the data files targeted, and the operations to be performed.
In Deployment Tool, the JTAG Full VME Embedded software will then take the device chain information and generate the VME file. If a non-Lattice device is in the chain, you must add a JTAG-SVF device and supply the SVF file. For chains with JTAG-SVF devices, JTAG Full VME Embedded generates two
VME files. You can use one or both files to program the device.
To generate a VME file:
1. In Programmer, create a project, and add the target devices into the chain with the appropriate operations and data files. If a non-Lattice device is in the chain, set the device as a JTAG-SVF device and provide the appropriate SVF file, SVF vendor, and TCK frequency. Refer to
Programmer online help for more information on how to use Programmer.
2. Save the Programmer project (.xcf).
3. In Deployment Tool, choose Create New Deployment.
4. For Function Type, choose Embedded System.
51
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
5. For Output Type, choose JTAG Full VME Embedded, then click OK.
6. In the Step 1 of 4 dialog box, select the XCF file, and click Next.
7. In the Step 2 of 4 dialog box, elect the desired file options. For detailed option descriptions, including the option that allows you to generate a
HEX (.c) file, see the Deployment Tool online help.
8. Click Next.
9. In the Step 3 of 4 dialog box, in the Output File box, specify the location and file name of the VME file.
10. Click Next.
11. In the Step 4 of 4 dialog box, click Generate.
Deployment Tool generates the VME file depending upon the options you have chosen, and returns a message indicating that the process succeeded or failed.
Testing VME Files
Use the Download Debugger to process the VME file using any of the Lattice programming cables. Refer to Download Debugger online help for details.
This processor can run through port 0x0378 of the parallel port using the
Lattice download cable.
VME files can also be processed using the command line. See Running the
Deployment Tool from the Command Line online help for details.
52
Converting an SVF File to VME File
VME files can also be generated the traditional way by using the svf2vme source code. The utility will expect an SVF file as argument.
Choosing the File-Based or EPROM-
Based Version
To generate a PROM-based VME, select the “Generate HEX (.c) File” option in the Deployment Tool Step 2 of 4 dialog box.The programming engines of the file-based and PROM-based processors are identical in the way they handle the VME commands. Their difference lies in the way they interface with VME data. For a convenient demo, the file-based version assigns a file pointer to the binary VME file directly. The pointer is assigned based on a command line argument. With some minor modification, this version is useful for embedded high-level 32-bit microprocessors that can dynamically allocate
RAM and have large amounts of data and code memory. For more modest
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded embedded systems or smaller processors, the PROM-based version is useful because the memory resources are completely defined when compiling the executable.The VME file is converted to one or more C files and a header file that are compiled with the core routines.
Customizing for the Target Platform
The main routines that will require customization are in the hardware.c file.
They include the routines for reading from and writing to the JTAG pins and a delay routine. These routines are well commented in hardware.c and are at the top of the file. In readPort(), a byte of data is read from the input port. In writePort(), a byte of data is written to the output port. In ispVMDelay(), the system delays for the specified number of milliseconds or microseconds. The port mapping is set at the top of the hardware.c file.
The source code files are written in ANSI C. The JTAG Full VME Embedded source codes are located in the <install_path>\embedded_source directory.
See Also
JTAG Full VME Embedded Required User Changes
Advanced Issues
Since SVF files are serial in nature, many vendors have options on the type of operations to be performed when generating the SVF files. If an SVF file is too large for the targeted embedded application, consider removing optional operations or breaking up the operations by creating multiple SVF files. This approach is much better than arbitrarily dividing the VME file.
Programming Tools User Guide
EPROM-based JTAG Full VME
Embedded User Flow
This appendix details the steps the user must take to use the EPROM-based
JTAG Full VME Embedded.
Step 1. Create Chain With Programmer
Using Programmer, add the target devices into the chain with the appropriate operations and data files. If a non-Lattice device is in the chain, set the device as a JTAG-SVF device and provide the appropriate SVF file, SVF vendor, and
TCK frequency. For more information on supporting non-Lattice devices, see
Programmer’s on-line help documentation.
Step 2. Generate VME File
Use the Deployment Tool to generate the VME file. Refer to the Deployment
Tool online help for more information on Deployment Tool.
53
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Figure 16: EPROM-based JTAG Full VME Embedded User Flow
54
Step 3. Convert VME to HEX
A HEX file can be created from a VME file by using the vme2hex source code that is shipped with Programmer, or by selecting the Generate HEX (.c) File option in Deployment Tool. This source code can be found in the installation path of Programmer, under the
<install_path>\embedded_source\vmembedded\sourcecode\svf2vme. A HEX file is a C-programming language file that has the VME byte codes converted and stored in an array.
Step 4. Modify EPROM-based Source Code
The file hardware.c must be modified to target the embedded system. In particular, the following functions must be changed to be able to write, read, and observe the delay, respectively:
void writePort( unsigned char a_ucPins, unsigned char a_ucValue ) unsigned char readPort() void ispVMDelay(unsigned int delay_time)
Step 5. Compile Source Code and HEX Files
Combine the source code and HEX files into a project to be compiled. This may be done by using a microcontroller compiler.
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Programming Engine Flow
The programming engine of the JTAG Full VME Embedded is driven by the byte codes of the VME file. The byte codes instruct the programming engine as to what sequence of functions to follow in order to shift in instructions, move the TAP controller state machine, shift data in and out of the device, and observe delays.
The TAP controller is a synchronous state machine that is based on the TMS
(Test Mode Select) and TCK (Test Clock) signals of the TAP and controls the sequence of operations of the circuitry defined by the IEEE 1149.1 standard.
The TCK signal can be driven at a maximum of 25 MHz. JTAG devices in the chain may limit the TCK speed. Confirm the Maximum TCK for all the devices in the programming chain.
Figure 17: TAP Controller State Diagram
Programming Tools User Guide
In the Shift-DR state, a decoder is present to select which shift register is enabled and connects it between TDI and TDO. The following are the shift registers: Address Shift Register, Data Shift Register, 32-bit Shift Register, and Bypass. The 32-bit Shift Register is used to store the ID code and
55
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
USERCODE. The first bit clocked into any of the registers is placed into the
MSB, and data is shifted towards TDO as additional bits are clocked in.
Figure 18: Shift Registers
56
The engine core is implemented as a switch statement. The cases in this switch statement perform specialized functions based on the byte code and its operand(s). These functions may end up calling other switch statements, calling the engine core recursively, setting global variable values, or interfacing with the device directly. Once the byte code instruction has been executed, it returns to the main switch statement to process the next byte.
The processor begins by calculating the 16-bit CRC of the VME file and comparing it against the expected CRC. If that is successful, the processor then verifies the version of the VME file to make sure it is supportable. The version is an eight byte ASCII of the format ____<Major
Version>.<Minor Version>
, where <Major Version> and <Minor
Version> are digits 0-9. If the version verification fails, the processor returns the error code –4 to indicate a file error.
The Main Engine Switch calls the appropriate case statements based on the incoming byte code from the VME. Unrecognized byte codes will result in the program exiting with the error code –4 to indicate a file error.
STATE Case Statement
The STATE case statement expects a state following the STATE byte code to instruct the processor to step the IEEE 1149.1 bus to the next state. The state must be a valid stable state, which is IRPAUSE, DRPAUSE, RESET, or IDLE
SIR Case Statement
The SIR case statement begins by extracting the size of the register. The size will be used later to indicate how many bits of data will be sent or read back from the device. If the flow control has been set to CASCADE, then the processor shifts the device to the SHIFTIR. The presence of CASCADE in the flow control indicates that the SIR instruction is targeting over 64Kb of data and has been broken down to ease the memory requirements.
Programming Tools User Guide
Figure 19: Main Engine Switch
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Figure 20: STATE Case Statement
Programming Tools User Guide
If CASCADE has not been set, then the processor shifts the device into the safe state IRPAUSE, and then to SHIFTIR. If HIR exists (see HIR Case
Statement), then the processor will bypass the HIR. The SIR sub-switch is a switch that is based off of the byte codes that can potentially be found after the SIR byte code.
The TDI byte code indicates that there is data that needs to be shifted into the device. The data following the TDI byte will be extracted and decompressed, if compression were selected, and held in memory until it is ready to be shifted into the device.
57
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Figure 21: SIR Case Statement
58
The TDO byte code indicates that there is data that needs to be read and verified from the device. The data following the TDO byte will be extracted and decompressed, if compression were selected, and held in memory until it is ready to be compared against data in the device.
The XTDO byte code indicates that the TDO data is the TDI data of the previous frame, such as in the case of concurrent, or turbo, programming.
Data will not follow the XTDO byte code, resulting in a smaller VME. Instead, the previous frame’s TDI data will be used as the current TDO data.
The MASK byte code indicates that there is mask data that needs to be used when comparing the TDO values against the actual values read from the device. The data following the MASK byte will be extracted and decompressed, if compression were selected, and held in memory until it is ready to be used when comparing against data in the device.
The DMASK byte code indicates that there is dynamic mask data that needs to be used when comparing the boundary scan. The data following the
DMASK byte will be extracted and decompressed, if compression were selected, and held in memory until it is ready to be used when comparing against the boundary scan.
The CONTINUE byte code terminates the SIR instruction. When this byte is encountered, it indicates that the processor is ready to send or read and verify data from the device using the data it is currently holding in memory. If any byte codes other than TDI, TDO, XTDO, MASK, DMASK, and CONTINUE were encountered in the SIR Sub-switch, the program will exit with the error code –4, indicating a file error.
If the TDO or XTDO byte code were encountered in the SIR sub-switch, then that indicates that the SIR instruction is going to read data from the device, else the SIR instruction is going to send data to the device.
If reading and verifying data from the device were successful, the processor checks if the CASCADE flag has been set. If it is set, the control returns to the
Main Engine Switch. If the flag is off, the processor checks if TIR exists (see
TIR Case Statement). If it exists, then the trailer devices must be bypassed.
Next, it shifts the device to the stable state that followed the ENDIR byte code
Programming Tools User Guide
Figure 22: SIR Case Statement Continued
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Programming Tools User Guide
(see ENDIR Case Statement). The control returns back to the Main Engine
Switch.
If reading and verifying data from the device were unsuccessful, the processor checks if the vendor has been set to Xilinx. If the vendor is Xilinx, repeat the read loop up to 30 times before returning an error. If the vendor is not Xilinx, the processor bypasses the TIR if there are trailer devices. Next, it shifts the device to the stable state that followed the ENDIR byte code. The error code returned is –1 to indicate a verification failure.
If TDO or XTDO were not encountered in the SIR sub-switch, then the processor sends data to the device. If the CASCADE flag has been set, the control returns to the Main Engine Switch. If TIR exists, then the trailer devices must be bypassed. Next, it shifts the device to the stable state that followed the ENDIR byte code. The control returns back to the Main Engine
Switch.
SDR Case Statement
The SDR case statement works similar to the SIR. It begins by extracting the size of the register. The size will be used later to indicate how many bits of data will be sent or read back from the device. If the flow control has been set to CASCADE, then the processor shifts the device to the SHIFTIR. The presence of CASCADE in the flow control indicates that the SDR instruction is targeting over 64Kb of data and has been broken down to ease the memory requirements.
59
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Figure 23: SDR Case Statement
60
If CASCADE has not been set, then the processor shifts the device into the safe state DRPAUSE, and then to SHIFTDR. If HDR exists (see HDR Case
Statement), then the processor will bypass the HDR. The SDR sub-switch is a switch that is based off the byte codes that can potentially be found after the
SDR byte code.
The TDI byte code indicates that there is data that needs to be shifted into the device. The data following the TDI byte will be extracted and decompressed, if compression were selected, and held in memory until it is ready to be shifted into the device.
The TDO byte code indicates that there is data that needs to be read and verified from the device. The data following the TDO byte will be extracted and decompressed, if compression were selected, and held in memory until it is ready to be compared against data in the device.
he XTDO byte code indicates that the TDO data is the TDI data of the previous frame, such as in the case of concurrent, or turbo, programming.
Data will not follow the XTDO byte code, resulting in a smaller VME. Instead, the previous frame’s TDI data will be used as the current TDO data.
The MASK byte code indicates that there is mask data that needs to be used when comparing the TDO values against the actual values read from the device. The data following the MASK byte will be extracted and decompressed, if compression were selected, and held in memory until it is ready to be used when comparing against data in the device.
The DMASK byte code indicates that there is dynamic mask data that needs to be used when comparing the boundary scan. The data following the
DMASK byte will be extracted and decompressed, if compression were selected, and held in memory until it is ready to be used when comparing against the boundary scan.
The CONTINUE byte code terminates the SDR instruction. When this byte is encountered, it indicates that the processor is ready to send or read and verify data from the device using the data it is currently holding in memory. If any byte codes other than TDI, TDO, XTDO, MASK, DMASK, and CONTINUE were encountered in the SDR Sub-switch, the program will exit with the error code –4, indicating a file error.
Programming Tools User Guide
Figure 24: SDR Case Statement Continued
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Programming Tools User Guide
If the TDO or XTDO byte code were encountered in the SDR sub-switch, then that indicates that the SDR instruction is going to read data from the device, else the SDR instruction is going to send data to the device.
If reading and verifying data from the device were successful, the processor checks if the CASCADE flag has been set. If it is set, the control returns to the
Main Engine Switch. If the flag is off, the processor checks if TDR exists (see
TDR Case Statement). If it exists, then the trailer devices must be bypassed.
Next, it shifts the device to the stable state that followed the ENDDR byte code (see ENDDR Case Statement). The control returns back to the Main
Engine Switch.
If reading and verifying data from the device were unsuccessful, the processor checks if the vendor has been set to Xilinx. If the vendor is Xilinx, repeat the read loop up to 30 times before returning an error. If the vendor is not Xilinx, the processor bypasses the TIR if there are trailer devices. Next, it shifts the device to the stable state that followed the ENDIR byte code. The error code returned is –1 to indicate a verification failure.
If TDO or XTDO were not encountered in the SDR sub-switch, then the processor sends data to the device. If the CASCADE flag has been set, the control returns to the Main Engine Switch. If TDR exists, then the trailer devices must be bypassed. Next, it shifts the device to the stable state that followed the ENDDR byte code. The control returns back to the Main Engine
Switch.
61
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
XSDR Case Statement
The XSDR case statement works exactly like the SDR case statement, except that it sets the EXPRESS flag. The EXPRESS flag indicates to the processor that the VME is performing concurrent programming. Therefore, the TDO data shall use the previous frame’s TDI data. This reduces the VME size drastically because the data is not duplicated.
WAIT Case Statement
The WAIT case statement expects a number following the WAIT byte code to represent the number of milliseconds of delay the device must observe. The delay is observed immediately. The user must update the delay function in the source code to make the target embedded system observe the delay duration correctly.
Figure 25: WAIT Case Statement
TCK Case Statement
The TCK case statement expects a number following the TCK byte code to represent the number of clocks that the device must remain in the run test idle state. The clock cycles are executed immediately into the device.
Figure 26: TCK Case Statement
ENDDR Case Statement
The ENDDR case statement expects a state following the ENDDR byte code to represent the TAP state that the processor shall move the device to after an
SDR instruction. This state will be stored in a global variable.
62
Programming Tools User Guide
Figure 27: ENDDR Case Statement
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
ENDIR Case Statement
The ENDIR case statement expects a state following the ENDIR byte code to represent the TAP state that the processor shall move the device to after an
SIR instruction. This state will be stored in a global variable.
Figure 28: ENDIR Case Statement
HIR Case Statement
The HIR case statement expects a number following the HIR byte code to represent the number of header devices. The number will be stored in a global variable and the processor will issue this number of bypasses prior to executing an SIR instruction.
Figure 29: HIR Case Statement
TIR Case Statement
The TIR case statement expects a number following the TIR byte code to represent the number of trailer devices. The number will be stored in a global variable and the processor will issue this number of bypasses after executing an SIR instruction.
Figure 30: TIR Case Statement
Programming Tools User Guide
63
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
HDR Case Statement
The HDR case statement expects a number following the HDR byte code to represent the number of header register bits. The number will be stored in a global variable and the processor will issue this number of bypasses prior to executing an SDR instruction.
Figure 31: HDR Case Statement
TDR Case Statement
The TDR case statement expects a number following the TDR byte code to represent the number of trailer register bits. The number will be stored in a global variable and the processor will issue this number of bypasses after executing an SDR instruction.
Figure 32: TDR Case Statement
64
MEM Case Statement
The MEM case statement expects a number following the MEM byte code to represent the maximum frame size in bits. Memory buffers will be allocated for
TDI, TDO, MASK, and DMASK data according to the maximum number.
Figure 33: MEM Case Statement
VENDOR Case Statement
The VENDOR case statement expects the vendor type following the
VENDOR byte code to represent the vendor the VME supports. Different vendors require different programming algorithms that must be supported.
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
This byte notifies the embedded processor to enable the specified vendor support.
Figure 34: VENDOR Case Statement
SETFLOW Case Statement
The SETFLOW case statement expects an instruction following the
SETFLOW byte code to instruct the embedded processor to enable certain properties during execution. This is useful for cascading and looping VME files, where the processor flow must change in order to take advantage of these features.
Figure 35: SETFLOW Case Statement
RESETFLOW Case Statement
The RESETFLOW case statement works to reset the properties enabled during the SETFLOW case statement.
Figure 36: RESETFLOW Case Statement
Programming Tools User Guide
HEAP Case Statement
The HEAP case statement expects a number following the HEAP byte code to indicate the size of the upcoming repeat loop. In the file-based JTAG Full
VME Embedded, this size is used to dynamically allocate memory to hold the repeat loop. In the EPROM-based embedded, the heap array is set to point to the heap buffer in the HEX file.
65
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Figure 37: HEAP Case Statement
REPEAT Case Statement
The REPEAT case statement is executed if the VME were generated with the looping option. A looping VME attempts to reduce the VME size by forming loops around similar algorithm. Following the REPEAT byte code, a number indicating the number of repeats is extracted. The heap buffer is build by reading the number of HEAP size (see HEAP case statement) bytes and storing them in memory. Recursive calls are made back to the Main Engine
Switch, which will process the byte codes within the heap buffer. The recursive calls end when the repeat size is zero.
Figure 38: REPEAT Case Statement
66
ENDLOOP Case Statement
The ENDLOOP byte code terminates a loop iteration and shall be encountered only when the embedded processor is processing a repeat loop.
This byte code shall always be the last byte of the heap buffer. When this byte code is found, the control returns back to the looping control, where the repeat size gets decremented and the next iteration of the loop begins, unless the repeat size is zero.
Programming Tools User Guide
Figure 39: ENDLOOP Case Statement
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
ENDVME Case Statement
The ENDVME case statement exits the main engine switch. This byte code is the last byte of the VME.
Figure 40: ENDVME Case Statement
SHR Case Statement
The SHR case statement expects a number following the SHR byte code to perform a right shift on the TDI data buffer. At this point the TDI data buffer should store the register address. By simply right shifting the register address to increment to the next frame instead of having the VME contain several register address buffers, the VME size is reduced.
Figure 41: SHR Case Statement
SHL Case Statement
The SHL case statement works similar to the SHR case statement, except that it shifts to the left.
Figure 42: SHL Case Statement
Programming Tools User Guide
67
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
FREQUENCY Case Statement
The FREQUENCY case statement expects a number following the
FREQUENCY byte code to establish the TCK frequency.
Figure 43: FREQUENCY Case Statement
68
VUES Case Statement
The VUES case statement sets the flow control register to indicate that the
VME is invoking the Continue If Fail feature. Under this condition, if the
USERCODE verification fails, then the embedded processor continues with programming the data. If the USERCODE verification passes, then the processor exits without programming.
COMMENT Case Statement
The COMMENT case statement is executed if the VME file were generated to support SVF comments. This statement expects a number to indicate the size of the comment. The comment is then read one byte at a time and displayed onto the terminal. It ends when the number of bytes processed equals the number indicating the size of the comment.
Figure 44: COMMENT Case Statement
HEADER Case Statement
The HEADER case Statement is executed if the VME file were generated with header information. Currently, this feature is not supported.
Figure 45: HEADER Case Statement
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
LCOUNT Case Statement
The LCOUNT case statement is executed if the VME file targets FLASH or
PROM devices. It allows the engine to repeatedly check the status of the device before programming the next block of data. This statement expects a number to indicate the number of status checks before issuing a failure return code. The engine will use an index to point to the repeated commands in a buffer and issue them to the device. The index is reset after each iteration.
This will continue until the number of status checks gets decremented to zero, or until the status is verified to be true.
Figure 46: LCOUNT Case Statement
LVDS Case Statement
The LVDS case statement informs the processor about the number of LVDS pairs and which are paired. This ensures that the processor will drive opposite values back into the pairs.
VME Byte Codes
Appendix C lists the byte codes that are found in the VME and interpreted by the embedded processor.
General Opcode
VMEHEXMAX
SCANMAX
Value
60000L
64000L
Description
Sets the HEX file maximum size to 60K
Sets the maximum data burst to 64K
Programming Tools User Guide
69
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
Formatting Opcode
CONTINUE
ENDVME
ENDFILE
Value
0x70
0x7F
0xFF
Description
Indicates the end of a VME line
Indicates the end of a VME file
Indicates the end of file
JTAG Opcode
RESET
IDLE
IRPAUSE
DRPAUSE
SHIFTIR
SHIFTDR
Flow Control
Opcode
INTEL_PRGM
CASCADE
REPEATLOOP
SHIFTRIGHT
SHIFTLEFT
VERIFYUES
Value
0x00
0x01
0x02
0x03
0x04
0x05
Traverse to TLR
Description
Traverse to RTI
Traverse to PAUSE IR
Traverse to PAUSE DR
Traverse to SHIFT IR
Traverse to SHIFT DR
Value
0x0001
0x0002
0x0008
0x0080
0x0100
0x0200
Description
Intelligent programming in effect
Currently splitting large SDR
Currently executing a repeat loop
Indicates the next stream needs a right shift
Indicates the next stream needs a left shift
Indicates Continue If Fail flag
Data Type Register
Opcode
EXPRESS
SIR_DATA
SDR_DATA
COMPRESS
TDI_DATA
TDO_DATA
MASK_DATA
HEAP_IN
LHEAP_IN
VARIABLE
CRC_DATA
CMASK_DATA
RMASK_DATA
READ_DATA
DMASK_DATA
Value
0x0001
0x0002
0x0004
0x0008
0x0010
0x0020
0x0040
0x0080
0x0200
0x0400
0x0800
0x1000
0x2000
0x4000
0x8000
Description
Simultaneous program and verify
SIR is the active SVF command
SDR is the active SVF command
Data is compressed
TDI data is present
TDO data is present
MASK data is present
Data is from the heap
Data is from the intelligent data buffer
Data is from a declared variable
CRC data is present
CMASK data is present
RMASK data is present
READ data is present
DMASK data is present
Hardware Opcode
signalENABLE signalTMS signalTCK signalTDI signalTRST
Value
0x1C
0x1D
0x1E
0x1F
0x20
Description
Assert the ispEN pin
Assert the MODE or TMS pin
Assert the SCLK or TCK pin
Assert the SDI or TDI pin
Assert the RESTE or TRST pin
70
Vendor Opcode
VENDOR
LATTICE
ALTERA
Value
0x56
0x01
0x02
Description
Indicates vendor opcode is following
Indicates Lattice or JTAG device
Indicates Altera device
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
XILINX
SVF Opcode Value
ENDDATA
RUNTEST
ENDDR
ENDIR
ENDSTATE
TRST
HIR
TIR
HDR
TDR ispEN
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
0x08
0x09
0x0A
FREQUENCY 0x0B
STATE
SIR
SDR
TDI
0x10
0x11
0x12
0x13
TDO 0x14
MASK 0x15
XSDR 0x16
XTDI 0x17
XTDO
MEM
WAIT
TCK
HEAP
REPEAT
LEFTPAREN
VAR
SEC
SMASK
MAX
ON
OFF
SETFLOW
RESETFLOW
CRC
CMASK
RMASK
READ
ENDLOOP
SECUREHEAP
0x49
0x50
0x59
0x60
SVF Opcode Value
VUES
DMASK
COMMENT
HEADER
0x61
0x62
0x63
0x64
FILE_CRC
LCOUNT
LDELAY
LSDR
LHEAP
LVDS
0x65
0x66
0x67
0x68
0x69
0x71
0x1C
0x1D
0x1E
0x1F
0x20
0x30
0x31
0x47
0x48
0x18
0x19
0x1A
0x1B
0x32
0x33
0x35
0x55
0x03 Indicates Xilinx device
Description
Indicates the end of the current SDR data stream
Indicates the duration to stay at the stable state
Indicates the stable state after SDR
Indicates the stable state after SIR
Indicates the stable state after RUNTEST
Assert the TRST pin
Specifies the sum of IR bits at lead
Specifies the sum of IR bits at end
Specifies the number of devices at lead
Specifies the number of devices at end
Assert the ispEN pin
Specifies the maximum clock rate to run the state machine
Move to the next stable state
Indicates the instruction stream is following
Indicates the data stream is following
Indicates the data stream following is fed into the device
Indicates the data stream is to be read and compare
Indicates the data stream following is the output mask
Indicates the data stream following is for simultaneous shift in and shift out
Indicates the data stream following is for shift in only and it must be stored for verifying on the next XSDR call
Indicates there is no data stream following, instead it should be retrieved from the previous XTDI token
Indicates the size of the memory needed to be allocated.
Indicates the duration of the delay at IDLE state
Indicates the number of clocks to pulse to TCK
Indicates the size of the memory needed to hole the loop
Indicates the beginning of a reap loop
Indicates the beginning of the data following the loop
Indicates a place holder for the data if looping option has been selected
Indicates the absolute time in seconds that must be observed
Indicates the mask for TDI data
Indicates the absolute maximum wait time
Assert the targeted pin
Dis-assert the targeted pin
Change the Flow Control Register
Clear the Flow Control Register
Indicates which bits may be used in CRC calculation
Indicates which bits shall be used in CRC calculation
Indicates which bits shall be used in Read and Save
Indicates which bits may be used in Read and Save
Indicates the end of the repeat loop
Byte encoded to secure the HEAP structure
Description
Indicates Continue If Fail option has been selected
Indicates SVF file has DMASK
Support SVF comments in VME file
Support header in VME file
Support CRC-protected VME file
Support intelligent programming.
Support intelligent programming.
Support intelligent programming.
Memory needed to hold intelligent data buffer
Support LVDS
Return Codes
Programming Tools User Guide
Value Description
71
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Full VME Embedded
VME_VERIFICATION_ERROR
VME_FILE_READ_FAILURE
VME_VERSION_FAILURE
VME_INVALID_FILE
VME_ARGUMENT_FAILURE
VME_CRC_FAILURE
-1
-2
-3
-4
-5
-6
Value returned when the expected data does not match the actual data of the device
Value returned when the VME file cannot be read
Value returned when the version is not supported
Value returned when an invalid opcode is encountered
Value returned when a command line argument is invalid
Value returned when the expected CRC does not match the calculated CRC.
Unsupported SVF Syntax
The following are the SVF syntax not supported by the SVF2VME utility:
TRST - The TRST command is ignored.
PIO - The PIO command will cause SVF2VME to exit with an error.
PIOMAP - The PIOMAP command will cause SVF2VME to exit with an error.
MAXIMUM - The optional parameter MAXIMUM is ignored. This may be found in the RUNTEST command.
SMASK - The optional parameter SMASK is ignored. This may be found in the HDR, HIR, TDR, TIR, SIR, or SDR commands.
Explicit state transitions in the STATE command that contain non-stable states will cause SVF2VME to exit with an error. Only transitions between stable states are supported in the table below.
STATE RESET is supported. However, it is strongly discouraged to be included into the SVF file. This statement causes the undesirable effect of having all the devices in the entire JTAG chain to be reseted.
72
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
Current State New State
RESET RESET
RESET
RESET
IDLE
DRPAUSE
RESET
IDLE
IDLE
IDLE
IDLE
DRPAUSE
DRPAUSE
DRPAUSE
DRPAUSE
IRPAUSE
IRPAUSE
IRPAUSE
IRPAUSE
IRPAUSE
RESET
IDLE
DRPAUSE
IRPAUSE
RESET
IDLE
DRPAUSE
IRPAUSE
RESET
IDLE
DRPAUSE
IRPAUSE
The following table indicates the paths taken between stable states.
State Path
RESET (NO CLOCK)
RESET-IDLE
RESET-IDLE-DRSELECT-DRCAPTURE-DREXIT1-DRPAUSE
RESET-IDLE-DRSELECT-IRSELECT-IRCAPTURE-IREXIT1-
IRPAUSE
IDLE-DRSELECT-IRSELECT-RESET
IDLE (NO CLOCK)
IDLE-DRSELECT-DRCAPTURE-DREXIT1-DRPAUSE
IDLE-DRSELECT-IRSELECT-IRCAPTURE-IREXIT1-IRPAUSE
DRPAUSE-DREXIT2-DRUPDATE-DRSELECT-IRSELECT-RESET
DRPAUSE-DREXIT2-DRUPDATE-IDLE
DRPAUSE (NO CLOCK)
DRPAUSE-DREXIT2-DRUPDATE-DRSELECT-IRSELECT-
IRCAPTURE-IREXIT1-IRPAUSE
IRPAUSE-IREXIT2-IRUPDATE-DRSELECT-IRSELECT-RESET
IRPAUSE-IREXIT2-IRUPDATE-IDLE
IRPAUSE-IREXIT2-IRUPDATE-DRSELECT-DRCAPTURE-
DREXIT1-DRPAUSE
IRPAUSE (NO CLOCK)
JTAG Slim VME Embedded
The JTAG Slim VME Embedded software, based on the serial vector format file, enables you to quickly and efficiently program chains of devices, thus improving productivity and lowering costs. The JTAG Slim VME Embedded code is designed for microcontrollers with limited resources, such as the 8051 microcontroller.
The JTAG Slim VME Embedded software behaves the same as the JTAG Full
VME Embedded. The difference is it is geared to a 8051 processor. The C code adds memory space keywords specific to the 8051 processor. The size of the devices which can be programmed are limited by the amount of contiguous SRAM available to the 8051 processor.
The JTAG Slim VME Embedded is available with installations of Diamond
Programmer. Its advantages over other embedded systems include:
Footprint of less than 3KB ROM – The small footprint is made possible by optimizing the JTAG Slim VME Embedded programming engine to use the least amount of code in the most efficient fashion.
Reduced RAM usage – The memory usage is fixed at a minimal set for all IEEE 1532-compliant devices. The number of global and local variables has been reduced to a minimum, and no data buffers are required to be held in memory.
Compressible algorithm and data – The programming data, calculated by multiplying the frame size by the number of frames, can increase the
ROM requirement substantially. For example, the device LC51024MV(B) has a frame size of 2624 with 388 frames, resulting in 125 KB of ROM.
Fortunately, the JTAG Slim VME Embedded can compress the programming data into sizes that are much smaller. The compression is performed frame by frame and is data file dependent.
Programming Tools User Guide
73
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
Sequential chain programming – The JTAG Slim VME Embedded can process multiple devices in the same chain, with mixed operations in sequential mode.
See Also
Using the PC-based JTAG Slim VME Embedded
Using the 8051-based JTAG Slim VME Embedded
JTAG Slim VME Embedded Source
Code
The source code for both the PC-based and the 8051-based JTAG Slim VME
Embedded can be found in the
<install_path>\embedded_source\slimembedded directory.
Each project has the following files. The major entry point for JTAG Slim VME
Embedded is slim_vme.c.
slim_vme.c
The slim_vme.c file is the only file that differs between the PCbased and the 8051-based embedded solutions. This difference is due to the way each of these interfaces to the VME algorithm and data files through the entry point. This file contains the main and entry point functions.
slim_pro.c
The slim_pro.c file provides the programming engine for the
JTAG Slim VME Embedded. The engine operates on the commands in the
VME algorithm, and fetches data from the VME data, if necessary. The engine is responsible for functions such as sending data, verifying data, observing timing delay, stepping through the state machine, decompression, and so on.
hardware.c
The only file that you should modify is hardware.c. This file contains the functions to read and write to the port and the timing delay
function. You must update these functions to target the desired hardware . The
released version targets the parallel port of the PC at address 0x0378 using
Lattice’s download cable.
opcode.h
The opcode.h file contains the definitions of the byte codes used in the VME algorithm format and programming engine.
debug.h
The debug.h file will print out debugging information if the preprocessor switch VME_DEBUG is defined in the project. This is an optional file to include.
windriver.c and windriver.h
The windriver.c and windriver.h files target the
JTAG Slim VME Embedded to Windows. These files will be compiled if the preprocessor switch VME_WINDOWS is defined in the project file. These files should be omitted when compiling the 8051-based JTAG Slim VME
Embedded onto an embedded platform.
See Also
74
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
Using the PC-based JTAG Slim VME
Embedded
The PC-based JTAG Slim VME Embedded is a quick and easy way to validate the VME files and the JTAG Slim VME Embedded programming engine by successfully processing the target chain of IEEE 1532 compliant devices using the parallel port of the PC.
The JTAG Slim VME Embedded system uses a compressed binary variation of SVF files, called VME, as input. Like the SVF file, the VME file contains high-level IEEE 1149.1 bus operations. These operations consist of scan operations and movements between the IEEE 1149.1 TAP states. However, unlike the SVF file, where the programming algorithm of the device is intermeshed with the programming data, the VME file is separated into a VME algorithm file and a VME data file. This separation of the algorithm and data allows the optimization of the JTAG Slim VME Embedded programming engine. It also allows you to mix VME data files with VME algorithm files, provided the chain and operations are the same.
Figure 9 shows an example of Slim VME embedded file generation for the
JTAG port.
Figure 47: Slim VME Embedded VME Flow
Programming Tools User Guide
The JTAG Slim VME Embedded capability is enabled only if all the following conditions are met:
All the devices in the chain are IEEE-1532 compliant.
Sequential mode is selected.
Synchronize Enable and Disable setting is unchecked.
Operation is not Read and Save or a display operation such as Calculate
Checksum or Display ID.
See Also
Generating JTAG Slim VME Embedded Files
75
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
Using the 8051-based JTAG Slim VME
Embedded
To program embedded systems using the 8051-based JTAG Slim VME
Embedded, you must generate the VME files as HEX to create the VME algorithm and data files as C programming files. Each file contains a C programming style byte buffer that holds the VME algorithm or data.
The HEX files must be compiled along with the 8051-based JTAG Slim VME
Embedded source code. The source code contains handles that allow the compiler to link the buffers of the hexadecimal files to the main source code.
The only source code file that you need to modify is the hardware.c file. You must implement methods to write and read to the hardware port, as well as observe the timing delay. You must modify the following functions according to the target platform: readPort writePort ispVMDelay
The following are optional functions that you may wish to modify in the hardware.c file in order to enable and disable the hardware conditions before and after processing:
EnableHardware
DisableHardware
See Also
Generating JTAG Slim VME Embedded Files
JTAG Slim VME Embedded Source Code
VME Algorithm Format
The VME algorithm file contains byte codes that represent the programming algorithm of the device or chain.
VME Symbol
STATE
SIR
SDR
TCK
WAIT
ENDDR
ENDIR
HIR
0x04
0x05
0x06
0x07
0x08
HEX Value
0x01
0x02
0x03
76
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
Programming Tools User Guide
VME Symbol
TIR
HDR
TDR
BEGIN_REPEAT
FREQUENCY
TDI
CONTINUE
END_FRAME
TDO
MASK
END_REPEAT
DATA
PROGRAM
VERIFY
ENDVME
DTDI
DTDO
0x13
0x14
0x15
0x16
0x0F
0x10
0x11
0x12
HEX Value
0x09
0x0A
0x0B
0x0C
0x0D
0x0E
0x17
0x18
0x19
The byte codes perform the same operations as the SVF commands, with the exception of BEGIN_REPEAT, CONTINUE, END_FRAME, END_REPEAT,
DATA, PROGRAM, VERIFY, ENDVME, DTDI, and DTDO.
The byte codes BEGIN_REPEAT, END_REPEAT, PROGRAM, VERIFY,
DTDI, and DTDO are used to support a repeating VME algorithm structure to minimize the algorithm size, a feature that the linear SVF does not provide.
The byte code CONTINUE appears at the end of every SIR and SDR instruction as a terminator.
The byte code END_FRAME appears at the end of every frame in the VME data as a terminator.
Translation from the SVF file to VME algorithm file is done command by command. For example, the following SVF line:
SIR 8 TDI (16); will be converted to the following VME line, in binary:
0x02 0x08 0x0E 0x68
The VME Algorithm file is similar to the SVF file with the following differences:
77
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
VME Algorithm uses byte codes from the table below to represent SVF commands
Fuse data and USERCODE have been removed
Looping algorithm
The following is an example of an EPV VME Algorithm file and the SVF translation for the LC4064V device:
Table 2: VME Algorithm Example
VME Algorithm Format
0x0A 0x00
0x08 0x00
0x0B 0x00
0x09 0x00
0x06 0x03
0x07 0x02
0x01 0x01
0x02 0x08 0x0E 0x68 0x0F
Serial Vector Format (SVF)
HDR 0;
HIR 0;
TDR 0;
TIR 0;
ENDDR DRPAUSE;
ENDIR IRPAUSE;
STATE IDLE;
SIR 8 TDI (16);
Description
Shift in the IDCODE instruction
0x01 0x01
0x03 0x20 0x0E 0xFF 0xFF 0xFF
0xFF 0x11 0xC2 0x09 0x01 0x80
0x12 0xFF 0xFF 0xF0 0x0F
0x02 0x08 0x0E 0x38 0x0F
STATE IDLE;
SDR 32 TDI (FFFFFFFF) TDO
(01809043) MASK (0FFFFFFF);
SIR 8 TDI (1C);
Verify the IDCODE
SDR 68 TDI (00000000000000000);
Shift in the PRELOAD instruction
Shift all zero data into boundary scan cells
0x03 0x44 0x0E 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00
0x0F
0x02 0x08 0x0E 0xA8 0x0F
0x01 0x01 0x04 0x03 0x05 0x14
0x01 0x01
0x02 0x08 0x0E 0xC0 0x0F
0x01 0x01 0x04 0x03 0x05 0x64
0x01 0x01
0x02 0x08 0x0E 0x84 0x0F
SIR 8 TDI (15);
RUNTEST IDLE 3 TCK 2.00E-002 SEC;
SIR 8 TDI (03);
RUNTEST IDLE 3 TCK 1.00E-001 SEC;
SIR 8 TDI (21);
Shift in ENABLE instruction
Execute RUNTEST instruction
Shift in ERASE instruction
Execute RUNTEST instruction
Shift in ADDRESS INIT instruction
0x01 0x01
0x02 0x08 0x0E 0xE4 0x0F
STATE IDLE;
SIR 8 TDI (27);
0x0C 0x5F 0x15 N/A
VME Algorithm Format Serial Vector Format (SVF)
0x03 0xE0 0x02 0x18 0x14 0x0F SDR 352 DTDI (DATA);
RUNTEST IDLE 3 TCK 1.30E-002 SEC;
Shift in PROGRAM INCR instruction
Begin PROGRAM repeat loop of size 95
Description
Notice the forth byte is
0x18, which is actually
DTDI. DTDI instructs the processor to send in data from the data buffer
Execute RUNTEST instruction 0x01 0x01 0x04 0x03 0x05 0x0D
0x01 0x01
0x13 N/A
0x02 0x08 0x0E 0x58 0x0F
0x03 0x20 0x18 0x14 0x0F
SIR 8 TDI (1A);
SDR 32 DTDI (DATA);
RUNTEST IDLE 3 TCK 1.30E-002 SEC;
Terminate the repeat algorithm
Shift in PROGRAM USERCODE instruction
Shift in the USERCODE The
USERCODE can be found in the data buffer.
Execute RUNTEST instruction 0x01 0x01 0x04 0x03 0x05 0x0D
0x01 0x01
0x02 0x08 0x0E 0x80 0x0F SIR 8 TDI (01); Shift in ADDRESS SHIFT instruction
78
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
Table 2: VME Algorithm Example (Continued)
0x03 0x5F 0x0E 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x02 0x0F
0x02 0x08 0x0E 0x54 0x0F
SDR 95 TDI
(400000000000000000000000);
SIR 8 TDI (2A);
0x0C 0x5F 0x16 N/A
RUNTEST IDLE 3 TCK 1.00E-003 SEC;
Shift in beginning address
Shift in READ INC instruction
Begin VERIFY repeat loop of size 95
Execute RUNTEST instruction 0x01 0x01 0x04 0x03 0x05 0x01
0x01 0x01
0x03 0xE0 0x02 0x0E 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x19 0x14 0x0F
0x13
0x02 0x08 0x0E 0xE8 0x0F
0x03 0x20 0x0E 0xFF 0xFF 0xFF
0xFF 0x19 0x14 0x0F
0x02 0x08 0x0E 0xF4 0x0F
SDR 352 TDI (0000000000000
00000000000000000000000000
00000000000000000000000000
00000000000000000000000) DTDO
(DATA);
Verify the frame against the data in the data buffer
N/A
SIR 8 TDI (17);
SDR 32 TDI (FFFFFFFF)
DTDO (DATA);
SIR 8 TDI (2F);
RUNTEST IDLE 3 TCK 1.30E-002 SEC;
Terminate the repeat algorithm
Shift in USERCODE instruction
Verify the USERCODE against the USERCODE in the data buffer
Shift in PROGRAM DONE instruction
Execute RUNTEST instruction 0x01 0x01 0x04 0x03 0x05 0x0D
0x01 0x01
0x01 0x01
0x02 0x08 0x0E 0x78 0x0F
STATE IDLE;
SIR 8 TDI (1E);
RUNTEST IDLE 3 TCK 1.30E-002 SEC;
Shift in DISABLE instruction
Execute RUNTEST instruction 0x01 0x01 0x04 0x03 0x05 0x0D
0x01 0x01
0x17 N/A End VME Algorithm
See Also
JTAG Slim VME Embedded Source Code
Generating JTAG Slim VME Embedded Files
VME Data Format
While the VME algorithm file contains the programming algorithm of the device, the VME data file contains the fuse and USERCODE patterns.
The first byte in the file indicates whether the data file has been compressed.
A byte of 0x00 indicates that no compression was selected, and 0x01 indicates that compression was selected. When compression has been selected, each frame is preceded by a frame compression byte to indicate whether the frame is compressible. This is necessary because even though you might elect to compress the VME data file, it is possible that a compressed frame will actually be larger than an uncompressed frame. When that happens, the frame is not compressed at all and the frame compression
Programming Tools User Guide
79
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded byte of 0x00 notifies the processor that no compression was performed on the frame.
When compression has not been selected, the VME data file becomes a direct translation from the data sections of the SVF file. The END_FRAME byte, 0x10, is appended to the end of every frame as a means for the processor to verify that the frame has indeed reached the end.
Uncompressed VME Data Format
0x00
<Frame 1>0x10
<Frame 2>0x10
…
<Frame N>0x10
Compressed VME Data Format
0x01
<Compress Byte><Frame 1>0x10
<Compress Byte><Frame 2>0x10
…
<Compress Byte><Frame N>0x10
The compression scheme used is based on the consecutive appearance of the 0xFF byte in a frame. This byte is ubiquitous because an all 0xFF data file is a blank pattern. When a consecutive number of n 0xFF bytes are encountered, the VME data file will have the byte 0xFF followed by the number n converted to hexadecimal, where n cannot exceed 255. For example, if the following were a partial data frame
FFFFFFFFFFFFFFFFFFFF12FFFFFF the resulting compressed data would be
0xFF 0x0A 0x12 0xFF 0x03
When the processor encounters the first byte 0xFF, it gets the next byte to determine how many times 0xFF is compressed. The next byte is 0x0A, which is ten in hexadecimal. This instructs the processor that 0xFF is compressed ten times. The following byte is 0x12, which is processed as it is.
The next byte is again 0xFF followed by 0x03, which instructs the processor that 0xFF is compressed three times.
See Also
JTAG Slim VME Embedded Source Code
Generating JTAG Slim VME Embedded Files
VME Required User Changes
To make the JTAG Full VME Embedded or JTAG Slim VME Embedded software work on your target system, you need to modify the following C functions in the hardware.c source code.
80
Programming Tools User Guide
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
Timer
The engine requires the ability to delay for fixed time periods. The minimum granularity of the delay is 1 microsecond. You can determine the type of delay. This can be a simple software timing loop, a hardware timer, or an operating system call, for example, sleep().
Port Initialization
The firmware needs to place the port I/O into a known state. The programming software assumes this has occurred.
Get Data Byte
The engine calls the GetByte() function to collect one byte from the VME or CPU bytestream.
Modify Port Register
The engine, as it parses the bitstream data, changes an in-memory copy of the data to be written onto the I/O pins. Calls to this function do not modify the I/O pins. The engine uses virtual types (for example, DONE_PIN) which this function turns into physical I/O pin locations
(for example, 0x400).
Output Data Byte
The engine calls this function to write the in-memory copy onto the I/O pins.
Input Status
This function is used by the engine to read back programming status information. The function translates physical pin locations (for example,
0x400) into virtual types used by the engine (for example, DONE_PIN).
Output Configuration Pins
Some systems may wish to use the FPGA
CFG pins. There is a separate function call to manipulate the CFG pins.
Bitstream Initialization
You must determine how you plan to get the bitstream into your memory system, pre-compiled, HEX file based, or dynamically installed. Whichever method you use the data structures which pin to the bitstream need to be initialized prior to the first GetByte function call.
See Also
Customizing for the Target Platform
JTAG Slim VME Embedded Source Code
Program Memory Requirement
The following figure illustrates the JTAG Slim VME Embedded program memory requirement.
81
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
Program Memory Allocation
The following figure illustrates the JTAG Slim VME Embedded program memory allocation.
82
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
File Based
(Bitstream File External)
PROM Based
(Bitstream File Integrated)
Sample Program Size
This page provides sample program size for JTAG Full VME Embedded,
JTAG Slim VME Embedded, and sysCONFIG Embedded.
JTAG Port
JTAG Full VME
Embedded
JTAG Slim
VME
Embedded
8-Bit 32-Bit
52KB
16-Bit
21KB 4.2KB
non-JTAG Port sysCONFIG
Embedded
32-Bit
48KB
16-Bit
19KB
Total
As Shown
52KB 21KB 4.2KB
48KB 19KB As Shown +
VME File Size
Programming Tools User Guide
VME File Size
Refer to “VME File Size” on page 43 for a table that compares VME file sizes
taking typical Lattice devices for examples.
83
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
Generating JTAG Slim VME Embedded
Files
The Slim VME files can be generated by using Deployment Tool as described as follows.
Figure 48: Slim VME File Generation Flow
84
In Programmer, create a project, and add the target Lattice IEEE 1532 compliant devices into the chain with the appropriate operations and data files. Refer to Programmer online help for more information on how to use
Programmer.
1. Save the Programmer project (.xcf).
2. In Deployment Tool, choose Create New Deployment.
3. For Function Type, choose Embedded System.
4. For Output Type, choose JTAG Slim VME Embedded, then click OK.
5. In the Step 1 of 4 dialog box, select the XCF file, and click Next.
6. To have the software check for a USERCODE match between the device and the VME file before programming, select the Verify USERCODE,
Program Device if Fails option.
Note
Synchronize Enable and Disable has been turned on while using Sequential mode, the software will force the VME file into Turbo mode.
7. In the Step 2 of 4 dialog box, elect the desired file options. For detailed option descriptions, including the option that allows you to generate a
HEX (.c) file, see the Deployment Tool online help. To significantly reduce the ROM required for storing the VME Data buffer in the embedded system, select Compress VME File.
8. Click Next.
9. In the Step 3 of 4 dialog box, in the Output File box, specify the location and file name of the VME algorithm and data files.
10. Click Next.
11. In the Step 4 of 4 dialog box, click Generate.
Programming Tools User Guide
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
Deployment Tool generates the VME files depending upon the options you have chosen, and returns a message indicating that the process succeeded or failed.
JTAG Slim VME Embedded Source
Code
Both the PC and 8051-based JTAG Slim VME Embedded source code can be found in the installation path of Programmer under the
<install_path>\embedded_source\slimembedded\sourcecode directory.
Each project requires the following files:
slim_vme.c
The file slim_vme.c is the only file to differ between the PC-based and 8051based embedded solutions. This difference is due to the way each interfaces to the VME Algorithm and Data files through the entry point. This file contains the main and entry point functions.
slim_pro.c
The file slim_pro.c provides the programming engine of the JTAG Slim VME
Embedded. The engine operates on the commands in the VME Algorithm, and fetches data from the VME Data if necessary. The engine is responsible for functions such as sending data, verifying data, observing timing delay, stepping through the state machine, decompression, and so on.
hardware.c
The only file that should be modified by the user is hardware.c. This file contains the functions to read and write to the port and the timing delay function. The user must update these functions to target the desired hardware being used. The released version targets the parallel port of the PC at address 0x0378 using Lattice's download cable.
opcode.h
The file opcode.h contains the definitions of the byte codes used in the VME
Algorithm format and programming engine.
85
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
debug.h
The file debug.h prints out debugging information if the preprocessor switch
VME_DEBUG were defined in the project. This is an optional file to include.windriver.c and windriver.h
The files windriver.c and windriver.h target the JTAG Slim VME Embedded to
Windows 95 and 98. These files are compiled if the preprocessor switch
VME_WINDOWS were defined in the project file. These files should be omitted when compiling the 8051-based JTAG Slim VME Embedded onto an embedded platform.
8051 JTAG Slim VME Embedded User
Flow
This appendix details the steps the user must take to use the 8051-based
JTAG Slim VME Embedded.
Figure 49: 8051 JTAG Slim VME Embedded User Flow
86
Step 1. Create Chain with Lattice IEEE 1532 Compliant Devices using
Programmer
Using Programmer, add the target IEEE 1532 compliant devices into the chain with the appropriate operations and data files. All the devices in the chain must be IEEE 1532 compliant. For more information on supporting non-
Lattice devices, see Programmer’s on-line help documentation.
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
Step 2. Generate VME File
Use the Deployment Tool to generate the VME file. By checking the HEX check box, the VME Algorithm and Data files will be generated as Cprogramming files with the Algorithm and Data stored in C-style byte buffers.
Refer to Deployment Tool online help for more information on using the
Deployment Tool.
Step 4. Modify Source Code File hardware.c
The 8051-based source code files are written in ANSI C and can be found in the installation path of Programmer under the <install_path>\ embedded_source\slimembedded\sourcecode\slim_vme_8051 directory. The file hardware.c is the only file that is required to be modified by the user. The user must modify the following functions according to the target platform: readPort writePort ispVMDelay
The following are optional functions that the user may wish to modify in order to enable and disable the hardware conditions before and after processing:
EnableHardware
DisableHardware
Step 5. Compile Source Code and VME HEX Files
Combine the source code and VME HEX files generated into a project to be compiled. This may be done by using a microcontroller development tool to create the project. The source codes windriver.c, windriver.h, and debug.h shall not be required to be added into the project.
Programming Tools User Guide
Programming Engine Flow
The programming engine of the JTAG Slim VME Embedded is driven by the byte codes of the VME Algorithm file. The Algorithm byte codes instruct the programming engine as to what sequence of functions to follow in order to shift in instructions, move the TAP controller state machine, shift data in and out of the device, and observe delays.
The TAP controller is a synchronous state machine that is based on the TMS
(Test Mode Select) and TCK (Test Clock) signals of the TAP and controls the sequence of operations of the circuitry defined by the IEEE 1149.1 standard.
The TCK signal can be driven at a maximum of 25 MHz for current Lattice
IEEE 1532 Compliant devices.
In the Shift-DR state, a decoder is present to select which shift register is enabled and connects it between TDI and TDO. The following are the shift registers: Address Shift Register, Data Shift Register, 32-bit Shift Register, and Bypass. The 32-bit Shift Register is used to store the ID Code and
87
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
Figure 50: TAP Controller State Diagram
USERCODE. The first bit clocked into any of the registers is placed into the
MSB, and data is shifted one bit towards TDO as additional bits are clocked in.
Figure 51: Shift Registers
88
The engine core is implemented as a switch statement. The cases in this switch statement perform specialized functions based on the byte code and its operand(s). These functions may end up calling other switch statements, calling the engine core recursively, setting global variable values, or interfacing with the device directly. Once the byte code instruction has been executed, it returns back to the main switch statement to process the next byte.
The processor begins by verifying the VME version of the algorithm file. The version is an eight byte ASCII of the format _SVME<Major Version>.<Minor
Version>, where <Major Version> and <Minor Version> are digits 0-9.
If the version verification fails, the processor returns the error code
ERR_WRONG_VERSION, or -4.
Programming Tools User Guide
Figure 52: Main Engine Switch
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
The Main Engine Switch calls the appropriate case statements based on the incoming byte code from the VME Algorithm buffer. Unrecognized byte codes will trigger the UNKNOWN case statement.
HIR Case Statement
The HIR case statement expects a number following the HIR byte code to represent the number of header devices. The number will be stored in a global variable and the processor will issue this number of bypasses prior to executing an SIR instruction.
Figure 53: HIR Case Statement
Programming Tools User Guide
89
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
TIR Case Statement
The TIR case statement expects a number following the TIR byte code to represent the number of trailer devices. The number will be stored in a global variable and the processor will issue this number of bypasses after executing an SIR instruction.
Figure 54: TIR Case Statement
HDR Case Statement
The HDR case statement expects a number following the HDR byte code to represent the number of header register bits. The number will be stored in a global variable and the processor will issue this number of bypasses prior to executing an SDR instruction.
Figure 55: HDR Case Statement
TDR Case Statement
The TDR case statement expects a number following the TDR byte code to represent the number of trailer register bits. The number will be stored in a global variable and the processor will issue this number of bypasses after executing an SDR instruction.
Figure 56: TDR Case Statement
90
ENDDR Case Statement
The ENDDR case statement expects a state following the ENDDR byte code to represent the TAP state that the processor shall move the device into after an SDR instruction. This state will be stored in a global variable.
Programming Tools User Guide
Figure 57: ENDDR Case Statement
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
ENDIR Case Statement
The ENDIR case statement expects a state following the ENDIR byte code to represent the TAP state that the processor shall move the device into after an
SIR instruction. This state will be stored in a global variable.
Figure 58: ENDIR Case Statement
WAIT Case Statement
The WAIT case statement expects a number following the WAIT byte code to represent the number of milliseconds of delay the device must observe. The delay is observed immediately. The user must update the delay function in the source code to make the target embedded system observe the delay duration correctly.
Figure 59: WAIT Case Statement
TCK Case Statement
The TCK case statement expects a number following the TCK byte code to represent the number of clocks that the device must remain in the run test idle state. The clock cycles are executed immediately into the device.
Figure 60: TCK Case Statement
Programming Tools User Guide
91
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
STATE Case Statement
The STATE case statement expects a state following the STATE byte code to instruct the processor to step the IEEE 1149.1 bus to the next state. The state must be a valid stable state, which is IRPAUSE, DRPAUSE, RESET, or IDLE
Figure 61: STATE Case Statement
SIR Case Statement
Figure 62: SIR Case Statement
92
The SIR case statement begins by extracting the size of the register. The size will be used later to indicate how many bits of data will be sent or read back from the device. The processor then shifts the device into the safe state
IRPAUSE, and then to the state SHIFTIR. If HIR exists (see HIR Case
Statement), then the processor will bypass the HIR. The SIR sub-switch is a switch that is based off of the byte codes that can potentially be found after the SIR byte code.
The TDI byte code indicates that there is data that needs to be shifted into the device. The processor will set the TDI index variable to point to the location where the TDI data begins in the algorithm buffer.
The DTDI byte code indicates that there is data to that needs to be shifted into the device. Unlike the TDI byte code, the DTDI byte code signals that the data will be coming from the data buffer. If the data buffer has compression turned on, the first byte of the data frame will be checked to see if the frame was indeed compressible.
The TDO byte code indicates that there is data that needs to be read and verified from the device. The processor will set the TDO index variable to point to the location where the TDO data begins in the algorithm buffer.
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
The DTDO byte code indicates that there is data that needs to be read and verified from the device. Unlike the TDO byte code, the DTDO byte code signals that the data will be coming from the data buffer. If the data buffer has compression turned on, the first byte of the data frame will be checked to see if the frame were indeed compressible.
The MASK byte code indicates that there is mask data that needs to be used when comparing the TDO values against the actual values scanned out of the device. The processor will set the MASK index variable to point to the location where the MASK data begins in the algorithm buffer.
The UNKNOWN case statement is the default for unrecognized byte codes.
This case returns the error code ERR_ALGO_FILE_ERROR, or -5, to indicate an error in the algorithm.
The CONTINUE byte code terminates the SIR instruction. When this byte is encountered, it indicates that the TDI, DTDI, TDO, DTDO, and MASK indexes are pointing to their correct locations and the processor is ready to send or read and verify data from the device.
Figure 63: SIR Case Statement Continued
Programming Tools User Guide
If the TDO or DTDO byte code were encountered in the SIR sub-switch, then that indicates that the SIR instruction is going to read data from the device, else the SIR instruction is going to send data to the device.
If reading and verifying data from the device were successful, the processor checks if TIR exists (see TIR Case Statement). If TIR exists, then the trailer devices must be bypassed. Next it shifts the device to the stable state that followed the ENDIR byte code (see ENDIR Case Statement). The control returns back to the Main Engine Switch.
93
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
If reading and verifying data from the device were unsuccessful, the processor checks if TIR exists. If TIR exists, then the trailer devices must be bypassed. Next it shifts the device to the stable state that followed the ENDIR byte code. The error code ERR_VERIFY_FAIL, or -1, is returned and the program exits.
If TDO or DTDO were not encountered in the SIR sub-switch, then the processor sends data to the device. If TIR exists, then the trailer devices must be bypassed. Next it shifts the device to the stable state that followed the
ENDIR byte code. The control returns back to the Main Engine Switch.
94
SDR Case Statement
The SDR case statement works similar to the SIR. It begins by extracting the size of the register. The size will be used later to indicate how many bits of data will be sent or read back from the device. The processor then shifts the device into the safe state DRPAUSE, and then to the state SHIFTDR. If HDR exists (see HDR Case Statement), then the processor will bypass the HDR.
The SDR sub-switch is a switch that is based off of the byte codes that can potentially be found after the SDR byte code.
The TDI byte code indicates that there is data that needs to be shifted into the device. The processor will set the TDI index variable to point to the location where the TDI data begins in the algorithm buffer.
The DTDI byte code indicates that there is data to that needs to be shifted into the device. Unlike the TDI byte code, the DTDI byte code signals that the data will be coming from the data buffer. If the data buffer has compression turned on, the first byte of the data frame will be checked to see if the frame were indeed compressible.
The TDO byte code indicates that there is data that needs to be read and verified from the device. The processor will set the TDO index variable to point to the location where the TDO data begins in the algorithm buffer.
The DTDO byte code indicates that there is data that needs to be read and verified from the device. Unlike the TDO byte code, the DTDO byte code signals that the data will be coming from the data buffer. If the data buffer has compression turned on, the first byte of the data frame will be checked to see if the frame were indeed compressible.
The MASK byte code indicates that there is mask data that needs to be used when comparing the TDO values against the actual values scanned out of the device. The processor will set the MASK index variable to point to the location where the MASK data begins in the algorithm buffer.
The UNKNOWN case statement is the default for unrecognized byte codes.
This case returns the error code ERR_ALGO_FILE_ERROR, or -5, to indicate an error in the algorithm.
The CONTINUE byte code terminates the SDR instruction. When this byte is encountered, it indicates that the TDI, DTDI, TDO, DTDO, and MASK indexes
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
.
are pointing to their correct locations and the processor is ready to send or read and verify data from the device.
Figure 64: SDR Case Statement
Figure 65: SDR Case Statement Continued
Programming Tools User Guide
If the TDO or DTDO byte code were encountered in the SDR sub-switch, then that indicates that the SDR instruction is going to read data from the device, else the SDR instruction is going to send data to the device.
If reading and verifying data from the device were successful, the processor checks if TDR exists (see TDR Case Statement). If TDR exists, then the trailer devices must be bypassed. Next it shifts the device to the stable state that followed the ENDDR byte code (see ENDDR Case Statement). The control returns back to the Main Engine Switch.
95
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
If reading and verifying data from the device were unsuccessful, the processor checks if TDR exists. If TDR exists, then the trailer devices must be bypassed. Next it shifts the device to the stable state that followed the
ENDDR byte code. The error code ERR_VERIFY_FAIL, or -1, is returned and the program exits.
If TDO or DTDO were not encountered in the SDR sub-switch, then the processor sends data to the device. If TDR exists, then the trailer devices must be bypassed. Next it shifts the device to the stable state that followed the ENDDR byte code. The control returns back to the Main Engine Switch.
BEGIN_REPEAT Case Statement
The BEGIN_REPEAT byte code makes it possible to loop the programming algorithm, thus requiring less ROM to hold the algorithm. Programming each frame requires one pass through the repeat loop. The ROM saved is substantial when one considers that a device can have several thousand frames. Instead of extrapolating the set of byte codes needed to program the frame several thousand times, only one set will be sufficient.
The BEGIN_REPEAT case statement begins by extracting the repeat size.
The repeat size is typically the number of frames in the device that is to be programmed. After the repeat size has been obtained, the next byte to extract is the PROGRAM or VERIFY token. If the PROGRAM byte were present, then a pointer must be set in the data buffer to designate the beginning of the programming data. If the VERIFY byte were present, then the processor must return to the beginning location of the data buffer. This method allows programming and verification to use one set of data, thus reducing the ROM required to hold the data buffer by half.
While the repeat size, or number of un-programmed frames, is greater than zero, the algorithm index is set to point to the beginning of the repeat and a recursive call is made to the Main Engine Switch to program the frame. When the frame is processed, the Main Engine Switch returns the control to the
BEGIN_REPEAT case statement. The repeat size is decremented and the process repeats until there are no frames left. The control then returns to the
Main Engine Switch. While in the repeat loop, any errors such as verification or algorithm errors would result in the repeat loop returning the error code and the program would exit.
END_REPEAT Case Statement
The END_REPEAT case statement works alongside the BEGIN_REPEAT case statement. When the END_REPEAT byte code is encountered, it returns the control to the caller, which is the recursive call made by BEGIN_REPEAT.
The END_REPEAT byte code appears at the end of the set of byte codes needed to program a frame.
96
Programming Tools User Guide
Figure 66: BEGIN_REPEAT Case Statement
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
Figure 67: END_REPEAT Case Statement
ENDVME Case Statement
The ENDVME case statement is the only case where the program can return a passing value. The case statement checks if HDR exists (see HDR Case
Statement). If HDR exists, then that indicates that there are still header devices that need to be programmed, thus the control returns to the Main
Engine Switch. If HDR does not exist, the return value is returned to the caller, which is the entry point function and the program ends.
Figure 68: ENDVME Case Statement
Programming Tools User Guide
UNKNOWN Case Statement
The UNKNOWN case statement is the default for unrecognized byte codes.
This case returns the error code ERR_ALGO_FILE_ERROR, or -5, to indicate an error in the algorithm.
97
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
Figure 69: UNKNOWN Case Statement
VME Algorithm and Format
The VME Algorithm and Data files are created by deconstructing an SVF file.
An SVF file is an ASCII file that contains the programming algorithm and data needed to program the device. The programming algorithm is described by statements that control the IEEE 1149.1 bus operations. When generating the
VME files, Deployment Tool separates the algorithm and data into the VME
Algorithm and Data files, respectively.
VME Algorithm Format
The VME Algorithm file is similar to the SVF file with the following differences:
VME Algorithm uses byte codes from the table below to represent SVF commands
Fuse data and USERCODE have been removed
Looping algorithm
The following is an example of an EPV VME Algorithm file and the SVF translation for the LC4064V device:
Table 3: VME Algorithm Example
VME Algorithm Format
0x0A 0x00
0x08 0x00
0x0B 0x00
0x09 0x00
0x06 0x03
0x07 0x02
0x01 0x01
0x02 0x08 0x0E 0x68 0x0F
Serial Vector Format (SVF)
HDR 0;
HIR 0;
TDR 0;
TIR 0;
ENDDR DRPAUSE;
ENDIR IRPAUSE;
STATE IDLE;
SIR 8 TDI (16);
Description
Shift in the IDCODE instruction
0x01 0x01
0x03 0x20 0x0E 0xFF 0xFF 0xFF
0xFF 0x11 0xC2 0x09 0x01 0x80
0x12 0xFF 0xFF 0xF0 0x0F
0x02 0x08 0x0E 0x38 0x0F
STATE IDLE;
SDR 32 TDI (FFFFFFFF) TDO
(01809043) MASK (0FFFFFFF);
SIR 8 TDI (1C);
Verify the IDCODE
SDR 68 TDI (00000000000000000);
Shift in the PRELOAD instruction
Shift all zero data into boundary scan cells
0x03 0x44 0x0E 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00
0x0F
0x02 0x08 0x0E 0xA8 0x0F
0x01 0x01 0x04 0x03 0x05 0x14
0x01 0x01
0x02 0x08 0x0E 0xC0 0x0F
SIR 8 TDI (15);
RUNTEST IDLE 3 TCK 2.00E-002 SEC;
SIR 8 TDI (03);
Shift in ENABLE instruction
Execute RUNTEST instruction
Shift in ERASE instruction
98
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
JTAG Slim VME Embedded
Table 3: VME Algorithm Example (Continued)
RUNTEST IDLE 3 TCK 1.00E-001 SEC; 0x01 0x01 0x04 0x03 0x05 0x64
0x01 0x01
0x02 0x08 0x0E 0x84 0x0F SIR 8 TDI (21);
Execute RUNTEST instruction
Shift in ADDRESS INIT instruction
0x01 0x01
0x02 0x08 0x0E 0xE4 0x0F
0x0C 0x5F 0x15
VME Algorithm Format
0x03 0xE0 0x02 0x18 0x14 0x0F
0x01 0x01 0x04 0x03 0x05 0x0D
0x01 0x01
0x13
RUNTEST IDLE 3 TCK 1.30E-002 SEC;
0x02 0x08 0x0E 0x58 0x0F
0x03 0x20 0x18 0x14 0x0F
0x03 0x5F 0x0E 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x02 0x0F
0x02 0x08 0x0E 0x54 0x0F
N/A
SIR 8 TDI (1A);
SDR 32 DTDI (DATA);
SIR 8 TDI (2A);
Terminate the repeat algorithm
Shift in PROGRAM USERCODE instruction
Shift in the USERCODE The
USERCODE can be found in the data buffer.
Execute RUNTEST instruction 0x01 0x01 0x04 0x03 0x05 0x0D
0x01 0x01
0x02 0x08 0x0E 0x80 0x0F
RUNTEST IDLE 3 TCK 1.30E-002 SEC;
SIR 8 TDI (01);
SDR 95 TDI
(400000000000000000000000);
Shift in ADDRESS SHIFT instruction
Shift in beginning address
0x0C 0x5F 0x16 N/A
RUNTEST IDLE 3 TCK 1.00E-003 SEC;
Shift in READ INC instruction
Begin VERIFY repeat loop of size 95
Execute RUNTEST instruction 0x01 0x01 0x04 0x03 0x05 0x01
0x01 0x01
0x03 0xE0 0x02 0x0E 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x19 0x14 0x0F
0x13
0x02 0x08 0x0E 0xE8 0x0F
0x03 0x20 0x0E 0xFF 0xFF 0xFF
0xFF 0x19 0x14 0x0F
0x02 0x08 0x0E 0xF4 0x0F
STATE IDLE;
SIR 8 TDI (27);
N/A
Serial Vector Format (SVF)
SDR 352 DTDI (DATA);
SDR 352 TDI (0000000000000
00000000000000000000000000
00000000000000000000000000
00000000000000000000000) DTDO
(DATA);
N/A
SIR 8 TDI (17);
SDR 32 TDI (FFFFFFFF)
DTDO (DATA);
SIR 8 TDI (2F);
RUNTEST IDLE 3 TCK 1.30E-002 SEC;
Shift in PROGRAM INCR instruction
Begin PROGRAM repeat loop of size 95
Description
Notice the forth byte is
0x18, which is actually
DTDI. DTDI instructs the processor to send in data from the data buffer
Execute RUNTEST instruction
Verify the frame against the data in the data buffer
Terminate the repeat algorithm
Shift in USERCODE instruction
Verify the USERCODE against the USERCODE in the data buffer
Shift in PROGRAM DONE instruction
Execute RUNTEST instruction 0x01 0x01 0x04 0x03 0x05 0x0D
0x01 0x01
0x01 0x01
0x02 0x08 0x0E 0x78 0x0F
STATE IDLE;
SIR 8 TDI (1E);
0x01 0x01 0x04 0x03 0x05 0x0D
0x01 0x01
RUNTEST IDLE 3 TCK 1.30E-002 SEC;
Shift in DISABLE instruction
Execute RUNTEST instruction
Programming Tools User Guide
99
E
MBEDDED
F
LOW
O
VERVIEW
:
Slave SPI Embedded
Table 3: VME Algorithm Example (Continued)
0x17 N/A End VME Algorithm
Customizing for the Target Platform
The source code files are written in ANSI C. The VME source codes are located in the <install_path>\embedded_source\vmembedded directory. The
JTAG Slim VME Embedded source codes can be found in the
<install_path>\embedded_source\slimembedded directory.
The main routines that will require customization are in the hardware.c file. It includes the routines for reading from and writing to the JTAG pins and a delay routine. These routines are well commented in hardware.c and are at the top of the file. In readPort(), a byte of data is read from the input port. In writePort(), a byte of data is written to the output port. In ispVMDelay(), the system delays for the specified number of milliseconds or microseconds. The port mapping is set at the top of the hardware.c file.
See Also
Slave SPI Embedded
Slave Serial Peripheral Interface (SPI) Embedded is a high-level programming solution that enables programming the LatticeXP2 and future
FPGA families with built-in SPI port through embedded system. This allows users to perform real-time reconfiguration to Lattice Semiconductor's FPGA families. The Slave SPI Embedded system is designed to be embeddedsystem independent, so it is easy to port into different embedded systems with little modifications. The Slave SPI Embedded source code is written in C code, so the user may compile the code and load it to the target embedded system.
The purpose of this usage note is to provide the user with information about how to port the Slave SPI Embedded source code to different embedded systems. The following sections describe the embedded system requirements and the modifications required to use Slave SPI Embedded source code.
This usage guide is updated for Slave SPI Embedded version 2.0. Major changes includes new format of data file, and Lattice parallel port and USB cable support. In the Slave SPI Embedded source code, there are updates in intrface.c and core.c, but no update in hardware.c. Version 2.0 updates will be marked with [New in version 2.0] tag.
100
Requirements
This section lists device requirements, embedded system requirements, and other requirements.
Programming Tools User Guide
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
Slave SPI Embedded
Device Requirements
Only Lattice Semiconductor's FPGA families with SPI port are supported.
Single device support. Multiple device support is not available.
The Slave SPI port must be enabled on the device in order to use the
Slave SPI interface. This is done by setting the SLAVE_SPI_PORT to
Enable using the Global Preferences spreadsheet in Diamond
Spreadsheet view.
Embedded System Requirements
A compiler supporting C code for the target embedded system is required.
A dedicated SPI interface that can be configured to Master SPI mode is preferred. However, if the embedded system does not have a built in SPI interface, the user may consider using a general peripheral I/O ports to implement SPI functionality. In this case, minimum of four peripheral I/O's are required, with at least one of them that can be tri-stated if needed.
Read and Save operations and display operations are not supported.
Other Requirements
The Slave SPI Embedded system requires memory space to store programming data file. The storage may be internal or external memory
(RAM, Flash, etc.). The user may also consider storing the programming data in an external system such as PC. In this case, the user needs to establish communication between the external system and the embedded system.
Slave SPI Embedded Algorithm Format
The Slave SPI algorithm file contains byte codes that represent the programming algorithm of the device or chain.
Table 4: Slave SPI Algorithm Format
SSPI Symbol Hex Value
STARTTRAN 0x10
CSTOGGLE 0x11
TRANSOUT
TRANSIN
0x12
0x13
RUNCLOCK 0x14
ENDTRAN 0x1F
101
E
MBEDDED
F
LOW
O
VERVIEW
:
Slave SPI Embedded
Table 4: Slave SPI Algorithm Format (Continued)
SSPI Symbol Hex Value
MASK 0x21
ALGODATA 0x22
PROGDATA 0x25
RESETDATA 0x26
PRODATAEH 0x27
REPEAT 0x41
ENDREPEAT 0x42
LOOP 0x43
ENDLOOP 0x44
STARTOFALGO 0x60
ENDOFALGO
HCOMMENT
0x61
0xA0
HENDCOMMENT
ALGOID
VERSION
BUFFERREQ
0xA1
0xA2
0xA3
0xA4
STACKREQ
MASKBUFREQ
HCHANNEL
HEADERCRC
COMPRESSION
HDATASET_NUM
HTOC
0xA5
0xA6
0xA7
0xA8
0xA9
0xAA
0xAB
102
Slave SPI Embedded Data Format
While the SSPI algorithm file contains the programming algorithm of the device, the SSPI data file contains the fuse and USERCODE patterns. The first byte in the file indicates whether the data file has been compressed. A byte of 0x00 indicates that no compression was selected, and 0x01 indicates that compression was selected.
When compression has been selected, each frame is preceded by a frame compression byte to indicate whether the frame is compressible. This is necessary because even though you might elect to compress the SSPI data file, it is possible that a compressed frame will actually be larger than an
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
Slave SPI Embedded uncompressed frame. When that happens, the frame is not compressed at all and the frame compression byte of 0x00 is added to notify the processor that no compression was performed on the frame.
Uncompressed Slave SPI Data Format
0x00
<Frame 1>0x10
<Frame 2>0x10
…
<Frame N>0x10
Compressed Slave SPI Data Format
0x01
<Compress Byte><Frame 1>0x10
<Compress Byte><Frame 2>0x10
…
<Compress Byte><Frame N>0x10
Generating Slave SPI Embedded Files
The Slave SPI Embedded files can be generated through Diamond
Deployment Tool by selecting the VME button on the toolbar menu. The Slave
SPI Embedded generation dialog allows the user to generate the file in hex (C compatible) array or binary. The binary Slave SPI file can be used by the PC version of Slave SPI Embedded and utilizes the extension *.sea for algorithm files, and *.sed for data files. Also, the binary file can be uploaded to internal or external memory of the embedded system if the user plans to implement the system in that manner.
The hex file is a C programming language file that must be compiled with the
EPROM-based version of Slave SPI Embedded processor and utilizes the extension *.c. The binary file is generated by default. Other options are available through the dialog, such as data file compression, adding comments to the algorithm file, or disable generating the algorithm or data file.
Modifications
The Slave SPI Embedded source code is installed in the
<install_path>\embedded_source\sspiembedded\sourcecode directory where you installed the Diamond Programmer. There are two directories in the src directory, SSPIEm and SSPIEm_eprom. The first directory, SSPIEm, contains the file-based Slave SPI Embedded source code, and can support sending and receiving multiple bytes over the channel. The second directory,
SSPIEm_eprom, contains the EPROM-based Slave SPI Embedded source code, which supports the algorithm and data being compiled with the process system.
In the files that require user modification, comments surrounded by asterisks
(*) will require the users' attention. These comments indicate that the following section may require user modification. For example:
//*********************************************************************
//* Example comment
//*********************************************************************
Programming Tools User Guide
103
E
MBEDDED
F
LOW
O
VERVIEW
:
Slave SPI Embedded
Before using the Slave SPI Embedded system, there are three sets of files (.c
/ .h) that need to be modified. The first set, hardware.c and hardware.h, must be modified. This file contains the SPI initialization, wait function, and SPI controlling functions. If the user would like to enable debugging functionalities, debugging utilities need to be modified in this file as well. [New in version 2.0] hardware.c source code supports transmitting and receiving multiple bytes at once. This approach may be faster in some SPI architecture, but it requires a buffer to store the entire frame data. If the user wishes to use single byte transmission, replace hardware.c and hardware.h with the ones in file sspiem_sbyte.zip.
The second set, intrface.c and intrface.h, contains functions that utilize the data and algorithm files. There are two sections in this file that requires attention. The first one is data section. When the processor in Slave SPI
Embedded system needs to process a byte of data, it calls function dataGetByte()
. Slave SPI Embedded version 2.0 requires data file no matter what operation it is going to process. Users are responsible to modify the function to fit their configuration. The second section is algorithm section.
In Programmer, there is the option to generate both the algorithm file and the data file in hex array format (C compatible). If the user wishes to compile the algorithm and data along with Slave SPI Embedded system, use the source code in the
<install_path>\embedded_source\sspiembedded\sourcecode\sspiem_eprom directory. Users only need to put the generated .c file in the same folder as
Slave SPI Embedded system code and then compile the whole thing. If the embedded system has internal memory that can be reached by address, using EPROM version of intrface.c is also ideal. For users who plan to put the algorithm and data in external storage, intrface.c and intrface.h may need modification.
[New in version 2.0] The third file set is SSPIEm.c and SSPIEm.h. Function
SSPIEm_preset()
provides the user to set which algorithm and data will be processed. This function needs to be modified according to users' configuration.
Below is information about functions the user is responsible to modify.
104
hardware.c
There is update in version 2.0 hardware.c source code. In previous version, users are responsible to modify function TRANS_tranceive_stream().
Version 2.0 source code, which support transmitting multiple bytes at once, includes two functions, TRANS_transmitBytes() and
TRANS_receiveBytes()
, that function TRANS_tranceive_stream() would call. Therefore, TRANS_tranceive_stream() no longer require user attention in this configuration, but the user is responsible to modify
TRANS_transmitBytes()
and TRANS_receiveBytes(). If the user wish to implement Slave SPI Embedded so it transmit one byte at a time, then
TRANS_tranceive_stream() need to be modified.
int SPI_init();
This function will be called at the beginning of the Slave SPI
Embedded system. Duties may include, but not limited to:
Programming Tools User Guide
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
Slave SPI Embedded
Turning on SPI port;
Enabling counter for wait function;
Configuring SPI peripheral IO ports (PIO);
Resetting SPI;
Initializing SPI mode (Master mode, channel used, etc);
Enabling SPI.
The function returns a 1 to indicate initialization successful, or a 0 to indicate fail.
int SPI_final();
This function will be called at the very end of the Slave SPI
Embedded system. The function returns a 1 to indicate success, or a 0 to indicate fail.
void wait(int ms);
This function takes a delay time (in milliseconds), and waits for the amount of delay time. This function does not need a return value.
int TRANS_starttranx(unsigned char channel);
This function will start an
SPI transmission. Duties may include, but not limited to:
Pulling Chip Select (CS) low;
Starting Clock;
Flushing read buffer.
If the dedicated SPI interface in the embedded system automatically starts the clock and pulls CS low, then this function only returns a 1. This function returns a 1 to indicate success, or a 0 to indicate fail.
int TRANS_endtranx();
This function will finalize an SPI transmission.
Duties may include, but not limited to:
Pulling CS high;
Terminating Clock.
If the dedicated SPI interface in the embedded system automatically terminates the clock and pulls CS high, then this function only returns a 1.
This function returns a 1 to indicate success, or a 0 to indicate fail.
int TRANS_cstoggle(unsigned char channel);
This function will toggle the CS of current channel. It will be called between TRANS_starttranx() and TRANS_endtranx(). It first pulls CS low, waits for a short period of time, and pulls CS high. A simple way to accomplish this is to transmit some dummy data to the device. One bit is enough to accomplish this. All one (1) for dummy is recommended, because usually the channel is held high during rest, and Lattice devices ignore opcode 0xFF (no operation). The function returns a 1 to indicate success, or a 0 to indicate fail.
int TRANS_runClk();
This function will run a minimum of three clocks on
SPI channel. It will be called after TRANS_endtranx() if extra clock are required. If the dedicated SPI interface does not allow free control of clock, a workaround is to enable the CS of another channel that is not being used.
105
E
MBEDDED
F
LOW
O
VERVIEW
:
Slave SPI Embedded
This way the device will still see the clock but the CS of current channel will stay high. The function returns a 1 to indicate success, or a 0 to indicate fail.
[New in version 2.0] int TRANS_transmitBytes (unsigned char *trBuffer, int trCount);
This function is available if the user wishes to implement transmitting multiple bits one byte at a time. It is responsible to transmit the number of bits, indicated by trCount, over the SPI port. The data to be transmitted is stored in trBuffer. Integer trCount indicates the number of bits being transmitted, which should be divisible by eight (8) to make it bytebounded. If trCount is not divisible by eight, pad the least significant bits of the transmitted data with ones (1).
[New in version 2.0] int TRANS_receiveBytes (unsigned char *rcBuffer, int rcCount);
This function is available if the user wishes to implement receiving multiple bits one byte at a time. It is responsible to receive the number of bits, indicated by rcCount, over the SPI port. The data received may be stored in rcBuffer. Integer rcCount indicates the number of bits being received, which should be divisible by eight (8) to make it byte-bounded. If rcCount
is not divisible by eight, pad the most significant bits of the received data with ones (1).
int TRANS_transceive_stream(int trCount, unsigned char *trBuffer, trCount2, int flag, unsigned char *trBuffer2);
This function is available for modification if the user wishes to implement transmission with one byte at a time. The function also appears in implementation of transmission with multiple bytes at once, but the user does not need to modify it.
For single byte transmission, this is the most complex function that needs to be modified. First, it will transmit the amount of bits specified in trCount with data stored in trBuffer. Next, it will have the following operations depending on the flag:
NO_DATA: End of transmission. trCount2 and trBuffer2 are discarded.
BUFFER_TX: Transmit data from trBuffer2.
BUFFER_RX: Receive data and compare it with trBuffer2.
DATA_TX: Transmit data from external data.
DATA_RX: Receive data from trbuffer2.
If the data is not byte-bounded and your SPI port only transmits and receives byte-bounded data, padding bits are required to make it byte-bounded. When transmitting non-byte-bounded data, add the padding bits at the beginning of the data. When receiving data, do not compare the padding, which are at the end of the transfer. The function returns a 1 to indicate success, or a 0 to indicate fail.
(optional) int dbgu_init();
This function initializes the debugging functionality. It is up to the user to implement it, and implementations may vary.
106
Programming Tools User Guide
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
Slave SPI Embedded
(optional) void dbgu_putint(int debugCode, int debugCode2);
This function will put a string and an integer to the debugging channel. It is up to the user to take advantage of these inputs.
SSPIEm.c
int SSPIEm_preset();
This function calls dataPreset() and algoPreset() functions to pre-set the data and algorithm. The input to this function depends on the configuration of the embedded system. This function returns 1 to indicate success, or 0 to indicate fail.
intrcface.c - Data Section
Global Variables
Global variables may vary due to different implementation.
[New in version 2.0] int dataPreset();
This function allows user to set which data will be used for processing. It returns 1 to indicate success, or 0 to indicate fail.
int dataInit (unsigned char *comp);
This function initializes the data. The first byte of the data indicates if the fuse data is compressed. It retrieves the first byte and stores it in the location pointed to by *comp. The fuse data starts at the second byte. The implementation may vary due to different configuration. The function returns a 1 to indicate success, or a 0 to indicate fail. For implementation that uses internal memory, which can be accessed by addressing, the following is an example implementation:
Points variable data to the beginning of the fuse data.
Resets count to 0.
int dataGetByte(int *byteOut);
This function gets one byte from data array and stores it in the location pointed to by byteOut. The implementation may vary due to different configuration. The function returns 1 to indicate success, or 0 to indicate fail. For implementation that uses internal memory, which can be accessed by addressing, here is a sample implementation:
Gets byte that variable data points to.
Points data to the next byte.
Count++.
int dataReset();
This function resets the data pointer to the beginning of the fuse data. Note that the first byte of the data is not part of the fuse data. It indicates if the data is compressed. The implementation may vary due to different configuration. The function returns a 1 to indicate success, or a 0 to indicate fail. For implementation that uses internal memory, which can be accessed by addressing, the following is an example implementation:
Points variable data to the beginning of the data array.
107
E
MBEDDED
F
LOW
O
VERVIEW
:
Slave SPI Embedded
Resets count to 0.
Note: This section is data utilize functions. Modification of this section is optional if the user wishes to compile the algorithm along with Slave SPI
Embedded system.
[New in version 2.0] int dataFinal();
This function is responsible to finish up the data. The implementation may vary due to different configuration. The function returns a 1 to indicate success, or a 0 to indicate fail.
108
intrface.c - Algorithm Section
Global variables
Global variables may vary due to different implementation.
[New in version 2.0] int algoPreset();
This function allows user to set which algorithm will be used for processing. It returns 1 to indicate success, or
0 to indicate fail.
int algoInit();
This function initializes the data. The implementation may vary due to different configuration. The function returns a 1 to indicate success, or a 0 to indicate fail.
In our implementation, it only sets algoIndex to 0.
int algoGetByte(unsigned char *byteOut);
This function gets one byte from the algorithm bitstream, and stores it in the location pointed to by byteOut
. The implementation may vary due to different configuration. The function returns a 1 to indicate success, or a 0 to indicate fail.
[New in version 2.0] int algoFinal();
This function is responsible to finish up the algorithm. The implementation may vary due to different configuration.
The function returns a 1 to indicate success, or a 0 to indicate fail.
intrface.c - Sample Configurations
There may be many different options to configure Slave SPI Embedded data file and algorithm file. The following are two possible configurations.
1. EPROM Approach
With this version, both algorithm and data are generated into C-compatible
Hex array and compiled along with Slave SPI Embedded source code. Here is how the functions are modified to fit this configuration:
Include both Hex arrays in the global scale.
Pass the pointer to the arrays to SSPIEm_preset(). In this function, pass the pointer to algoPreset() and dataPreset() functions, respectively. Both functions store the pointer in global variables defined in intrface.c.
Programming Tools User Guide
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
Slave SPI Embedded
In algoInit() and dataInit() functions, set the counters to zero (0).
In algoGetByte() and dataGetByte() functions, read a byte from the respective array, and increment the counter.
In dataReset() function, reset the counter to zero (0).
In algoFinal() and dataFinal() functions, set the pointer to both array to NULL. This is optional.
Although optional, it may be a good idea to keep track of the size of both data and algorithm arrays. The size of array may be passed to Slave SPI
Embedded through the preset functions.
If the embedded system uses internal memory that can be reached the same way as using array, this configuration may also fit into the embedded system.
If the user plans to use EPROM approach, intrface.c will be available, and the user may not need to modify it. The files intrface.c, intrface.h, SSPIEm.c, and
SSPIEm.h are in the
<install_path>/SSPIEmbedded/SourceCode/src/SSPIEm_eprom directory.
2. File System Approach
This approach is used when implementing Slave SPI Embedded commandline executable on PC. If the embedded system has similar file system, it may access the algorithm and data through the file system. Here is how the functions are modified to fit this configuration:
Pass the name of the algorithm and data file to SSPIEm_preset(). In this function, pass them to algoPreset() and dataPreset() functions, respectively. Both functions store the name of the file in global variables defined in intrface.c.
In algoInit() and dataInit() functions, open the file and check if they are readable. If the file is not opened as a stream, set the counter to zero (0).
In algoGetByte() and dataGetByte() functions, read a byte from the respective file, and increment the counter if needed.
In dataReset() function, reset the counter to zero (0), if needed. If the file is read as a stream, rewind the stream.
In algoFinal() and dataFinal() functions, close both files.
Usage
In order to use the Slave SPI Embedded system, include the Slave SPI
Embedded system in the target embedded system by including SSPIem.h to the header list. To start the processor, simply make this function call:
SSPIEm(unsigned int algoID);
109
E
MBEDDED
F
LOW
O
VERVIEW
:
I2C Embedded
Currently, the converter does not have algoID capability. This capability is reserved for future use. Use 0xFFFFFFFF for algoID.
Return Codes from Slave SPI
Embedded
The utility returns a 2 when the process succeeds, and returns number less than or equal 0 when it fails. Table 5 lists return codes from Slave SPI
Embedded.
Table 5: Return codes from Slave SPI Embedded
Results Return Code
Succeed 2
Process Failed
Initialize Algorithm Failed
Initialize Data Failed
Version Not Supported
Header Checksum Mismatch -4
Initialize SPI Port Failed -5
Initialization Failed
Algorithm Error
-6
-11
-2
-3
0
-1
Data Error
Hardware Error
Verification Error
-12
-13
-20
I
2
C Embedded
The physical I
2
C buss consists of two wires: SCL and SDA.
I
SCL is the clock line. It is used to synchronize all data transfers over the
2
C bus.
SDA is the data line.
The SCL & SDA lines are connected to all devices on the I
2
C bus. There must be a third wire connected to ground or 0 volts. There may also be a 5V wire for power distribution t he devices. Both SCL and SDA lines are “open drain” drivers, meaning that the device can drive its output low, but it cannot drive it high. For the line to be able to go high, you must provide pull-up resistors to the 5V supply. There should be a resistor from the SCL line to the 5V line and
110
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
I2C Embedded another from the SDA line to the 5V line. You only need one set of pull-up resistors for the entire I
2
C bus, as illustrated below.
Masters and Slaves
The devices on the I
2
C bus are either masters or slaves. The master is always the device that drives the SCL clock line. The slaves are the devices that respond to the master. Only a master can initiate a transfer over the I
2
C bus. A slave cannot initiate a transfer over the I
2
C bus. There can be, and usually are, multiple slaves on the I
2
C bus. However, there is normally only one master. It is possible to have multiple masters, but it is typical and not covered in this document. For the purposes of this document, the MachXO2 or MachXO3L device is always the slave.
MachXO2 or MachXO3L Slave I
2
C
Programming
When the master communicates to a slave (MachXO2 or MachXO3L for example) it begins by issuing a start sequence on the I
2
C bus. A start sequence is one of two special sequences defined for the I
2
C bus, the other being the stop sequence. The start sequence and stop sequence are the only time when the SDA (data line) is allowed to change while the SCL (clock line) is high. When data is being transferred, SDA must remain stable and not change while the SCL is high. The start and stop sequences mark the beginning and end of a transaction with the slave device.
Programming Tools User Guide
The primary I
2
C port of the Mach XO2 device can be used as a user I
2
C port function or as a device programming port. When used for device programming, the primary I
2
C port is a slave I
2
C with a default slave address
111
E
MBEDDED
F
LOW
O
VERVIEW
:
I2C Embedded of 7’b1000000 for 7-bit addressing or 10’b1111000000 for 10-bit addressing.
The primary I
2
C port must be enabled in order to support the device programming using the I
2
C protocol. This is done by setting the I2C_Port preference to ENABLE in the software. The I
2
C programming supports single device programming.
The sequence for device programming using the I
2
C follows the standard
Lattice device programming algorithm. The I
2
C bus hardware requirements, the timing requirements, and the receive/transmit protocols must follow the standard I
2
C specification. The definition of the SDA data time is the delay form the SCL falling edge 30% VDD to SDA falling edge 70% VDD. The SDA data setup time is the time requirement from the SDA falling edge 30% VDD to the SCL rising edge 30% VDD.
All the I
2
C slave commands consist of one byte op-code followed by three one-byte operand, except the ISC DISABLE command. The ISC DISABLE command for I
2
C programming consists of one byte op-code followed by two operands. I
2
C programming can also be done in the background. In this case, the ISC ENABLE command (0XC6) should be replaced by the
LSC_ENABLE_X command (0X74).
Using the PC-based I
2
C Embedded
Programming
The I
2
C Embedded system for MachXO2 or MachXO3L is a quick and easy way to validate I
2
C files and the I
2
C Embedded programming engine by successfully processing the target XO2 device using the FTDI USB2 Cable of the PC.
The programming algorithm of the device is separated into I
2
C algorithm file and I
2 optimization of the I mix I
2
C data file. This separation of the algorithm and data allows the
2
C embedded programming engine. It also allows you to
C data files with I
2
C algorithm files.
To access the PC-based I
2
C Embedded System, use the Diamond
Deployment Tool Version 1.4 or higher to add the MachXO2 or MachXO3L device. Then, select the I
2
C embedded programming options from the
Generate I
2
C dialog box. For more information, refer to the Deployment Tool online help.
The only source code file that must be modified is the hardware.c file. The source files can be found in
<install_path>\embedded_source\i2cembedded\src\i2cem diamond directory.
hardware.c
The only file that you should modify is hardware.c. This file contains the functions to read and write to the port and the timing delay function. You must update these functions to target the desired hardware.
112
Programming Tools User Guide
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
I2C Embedded
opcode.h
The opcode.h file contains the definitions of the byte codes used in the I
2
C algorithm format and programming engine.
i2c_core.c
The i2c_core.c file provides the programming engine for the I
2
C embedded system. The engine operates on the commands in the I
2
C algorithm, and obtains data from the I
2
C data, if necessary. The engine is responsible for functions such as sending data, verifying data, observing timing delay, decompression, and so on.
i2c_main.c
The i2c_main.c file is the only file that differs between the PC-based and the
8051-based embedded solutions. This difference is due to the way each of these interfaces to the I2C algorithm and data files through the entry point.
This file contains the main and entry point functions.
Using the 8051-based I
2
C Programming
To program embedded systems using the 8051-based I2C programming, you must generate the I
2
C files as HEX to create the I
2
C algorithm and data files as C programming files. Each file contains a C programming style byte buffer that holds the I
2
C algorithm or data.
The HEX files must be compiled along with the 8051-based I
2
C System source code. The source code contains handles that allow the compiler to link the buffers of the hexadecimal files to the main source code. The only source code file that you need to modify is the hardware.c file. The source files can be found in the
<install_path>\embedded_source\i2cembedded\src\i2cem_eprom directory.
hardware.c
The only file that you should modify is hardware.c. This file contains the functions to read and write to the port and the timing delay function. You must update these functions to target the desired hardware.
opcode.h
The opcode.h file contains the definitions of the byte codes used in the I
2
C algorithm format and programming engine.
113
E
MBEDDED
F
LOW
O
VERVIEW
:
I2C Embedded
i2c_core_eprom.c
The i2c_core.c file provides the programming engine for the I
2
C embedded system. The engine operates on the commands in the I
2
C algorithm, and fetches data from the I
2
C data, if necessary. The engine is responsible for functions such as sending data, verifying data, observing timing delay, decompression, and so on.
i2c_eprom.c
I
The i2c_main.c contains the main and entry point functions for 8051-based
2
C Programming.
I
2
C Algorithm Format
The I
2
C algorithm file contains byte codes that represent the programming algorithm of the device or chain.
Table 6: I
2
C Algorithm Byte Codes
I2C Symbol Hex Value
I2C_STARTTRAN 0x10
I2C_RESTARTTRAN
I2C_ENDTRAN
I2C_TRANSOUT
I2C_TRANSIN
I2C_RUNCLOCK
I2C_WAIT
I2C_LOOP
I2C_ENDLOOP
I2C_TDI
I2C_CONTINUE
I2C_TDO
I2C_MASK
I2C_BEGIN_REPEAT
I2C_END_REPEAT
I2C_END_FRAME
I2C_DATA
I2C_PROGRAM
I2C_VERIFY
0x17
0x18
0x19
0x1A
0x1B
0x1C
0x11
0x12
0x13
0x14
0x15
0x16
0x1D
0x1E
0x1F
0x20
0x21
0x22
114
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
I2C Embedded
Table 6: I
2
C Algorithm Byte Codes (Continued)
I2C Symbol Hex Value
I2C_DTDI
I2C_DTDO
I2C_COMMENT
I2C_ENDVME
0x23
0x24
0x25
0x7F
I
2
C Data Format
While the I
2
C algorithm file contains the programming algorithm of the device, the I
2
C data file contains the fuse and USERCODE patterns.
The first byte in the file indicates whether the data file has been compressed.
A byte of 0x00 indicates that no compression was selected, and 0x01 indicates that compression was selected. When compression has been selected, each frame is preceded by a frame compression byte to indicate whether the frame is compressible. This is necessary because even though you might elect to compress the I
2
C data file, it is possible that a compressed frame will actually be larger than an uncompressed frame. When that happens, the frame is not compressed at all and the frame compression byte of 0x00 notifies the processor that no compression was performed on the frame.
When compression has not been selected, the I
2
C data file becomes a direct translation from the data sections of the SVF file. The END_FRAME byte,
0x1F, is appended to the end of every frame as a means for the processor to verify that the frame has indeed reached the end.
Uncompressed I2C Data Format
0x00
<Frame 1>0x10
<Frame 2>0x10
…
<Frame N>0x10
Compressed I2C Data Format
0x01
<Compress Byte><Frame 1>0x10
<Compress Byte><Frame 2>0x10
…
<Compress Byte><Frame N>0x10
The compression scheme used is based on the consecutive appearance of the 0xFF byte in a frame. This byte is ubiquitous because an all 0xFF data file is a blank pattern. When a consecutive number of n 0xFF bytes are encountered, the I
2
C data file will have the byte 0xFF followed by the number n converted to hexadecimal, where n cannot exceed 255. For example, if the following were a partial data frame.
FFFFFFFFFFFFFFFFFFFF12FFFFFF the resulting compressed data would be:
0xFF 0x0A 0x12 0xFF 0x03
Programming Tools User Guide
115
E
MBEDDED
F
LOW
O
VERVIEW
:
I2C Embedded
When the processor encounters the first byte 0xFF, it gets the next byte to determine how many times 0xFF is compressed. The next byte is 0x0A, which is ten in hexadecimal. This instructs the processor that 0xFF is compressed ten times. The following byte is 0x12, which is processed as it is.
The next byte is again 0xFF followed by 0x03, which instructs the processor that 0xFF is compressed three times.
I
2
C Embedded Programming Required
User Changes
To make the I
2
C Embedded Programming software work on your target system, you need to modify the following C functions in the hardware.c source code.
Timer(SetI2Cdelay())
The engine requires the ability to delay for fixed time periods. The minimum granularity of the delay is 1 microsecond. You can determine the type of delay.
This can be a simple software timing loop, a hardware timer, or an operating system call, for example, sleep().
Port Initialization
The firmware needs to place the port I/O into a known state.
SetI2CStartCondition()
This function is used to issue a start sequence on the I
2
C Bus.
SetI2CreStartCondition()
This function is used to issue a start sequence on the I
2
C Bus.
SetI2CStopCondition()
This function is used to issue a stop sequence on the I
2
C Bus.
ReadBytesAndSendNACK()
This function is used to read the SDA pin from the port.
SendBytesAndCheckACK()
To apply the specified value to the SDA pin indicated.
116
Programming Tools User Guide
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
I2C Embedded
Generating I
2
C Files
This section describes how to generate I
2
C files. An .xcf file is required for the
MachXO2 or MachXO3L FPGA.
To generate an .xcf file for the MachXO2 or MachXO3L, if the .xcf file does not exist or has not yet been created:
1. Start the Diamond Programmer software and create a new Blank Project.
2. Select MachXO2 or MachXO3L as Device Family.
3. Select the Device Type according to your device.
4. Choose Edit > Device Properties, or right click on the device, and in the dropdown menu, choose Device Properties.
5. In the Device Properties dialog box:
In the Access Mode dropdown menu, choose I
2
C Interface
Programming.
In the Operation dropdown menu, choose the desired operation.
In the Programming File box, browse to your design’s .jed programming file.
In the I2C Slave Address box, enter the correct I
2
C slave address. The default address is 0x40.
6. Chose File > Save or File > Save (filename).xcf As... and give the file a name. Ensure that the extension of the file is xcf.
To generate I
2
C Files:
1. Start the Deployment Tool.
2. In the Getting Started dialog box, select Create New Deployment.
3. In the Function Type dropdown menu, choose Embedded System.
4. In the Output File Type dropdown menu, choose as I
2
C Embedded.
5. Click OK.
6. In the Step 1 of 4 dialog box, browse to the .xcf file you created with the
Programmer software, and select Input XCF file(s).
7. Click Next.
8. In the Step 2 of 4 dialog box, select Compress Embedded Files depending upon the requirement, select Generate Hex(.c) Files for 8051 micro-processor usages, and click Next.
9. In the Step 3 of 4 dialog box, select the Algorithm File and Data File to rename and change the location of the file name. Make sure the file name has the extension .iea and .ied, respectively, and click Next.
10. In the Step 4 of 4 dialog box, click Generate to generate the files.
11. The files will be generated as shown as below.
117
E
MBEDDED
F
LOW
O
VERVIEW
:
I2C Embedded
12. The Deployment Tool project can now be saved by selecting File > Save
As. The saved file will generate the same data file and algorithm file when loaded again.
13. Modify the Source Code File (hardware.c). The 8051-based source code files are written in ANSI C. The file hardware.c is the only file that is required to be modified by the user. The user must modify the following functions according to the target platform:
SetI2Cdelay()
SetI2CStartCondition()
SetI2CreStartCondition()
SetI2CStopCondition()
ReadBytesAndSendNACK( int length, unsigned char *a_ByteRead
, int NAck)
Where int length
= Number of bits to read
*a_ByteRead
= Buffer to store byte int NAck
- Option to send
0 = No
1 - Yes int SendBytesAndCheckACK(int length, unsigned char
*a_bByteSend
Where int length
= Number of bits to send
*a_bByteSend
= Buffer storing data to send
The following are optional functions that the user may wish to modify in order to enable and disable the hardware conditions before and after processing:
EnableHardware()
DisableHardware()
14. Compile Source Code and I2C HEX Files. Combine the source code and
I
2
C HEX files generated by Deployment Tool into a project to be compiled.
This may be done using a microcontroller development tool to create the project.
Modify the Delay Function
When porting Embedded I
2
C to a native CPU environment, the speed of the
CPU or the system clock that drives the CPU is usually known. The speed or the time it takes for the native CPU to execute one loop then can be calculated.
The for loop usually is compiled into the ASSEMBLY code as shown below:
LOOP: EDC RA;
JNZ LOOP;
118
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
I2C Embedded
If each line of assembly code needs four (4) machine cycles to execute, the total number of machine cycles to execute the loop is 2 x 4 = 8.
Usually: system clock = machine clock (the internal CPU clock).
Note
Some CPUs have a clock multiplier to double the system clock for the machine clock.
Let the machine clock frequency of the CPU be F (in MHz), then one machine cycle = 1/F.
The time it takes to execute one loop = (1/F) x 8.
It is obvious that the formula can be transposed into one microsecond = F/8.
Example: The CPU internal clock is set to 48 MHz, then one microsecond =
48/8 = 6.
The C code shown below can be used to create the millisecond accuracy. All that needs to be changed is the CPU speed.
Programming Tools User Guide
Choosing the File-Based or EPROM-Based Version
To generate a PROM-based I
2
C Embedded, select the “Generate HEX (.c)
File” option in the Deployment Tool Step 2 of 4 dialog box.The programming engines of the file-based and PROM-based processors are identical in the way they handle the VME commands. Their difference lies in the way they interface with I
2
C Embedded data. For a convenient demo, the file-based
119
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded version assigns a file pointer to the binary I
2
C Embedded file directly. The pointer is assigned based on a command line argument. With some minor modification, this version is useful for embedded high-level 32-bit microprocessors that can dynamically allocate RAM and have large amounts of data and code memory. For more modest embedded systems or smaller processors, the PROM-based version is useful because the memory resources are completely defined when compiling the executable.The I
2
C
Embedded file is converted to one or more C files and a header file that are compiled with the core routines.
sysCONFIG Embedded
The sysCONFIG Embedded software brings sysCONFIG port programming capability to Lattice Semiconductor's suite of FPGA devices on embedded
systems. The software offers a unique virtual programming engine that can
support the different programming algorithms of each device family. The
software is developed in ANSI C and is available in source code form to allow
users to target specific hardware.
The Diamond software may be used to generate a bitstream file. The file then must be converted to an embedded bitstream using Deployment Tool. The significance of the embedded bitstream is that it contains control pin instructions, which the sysCONFIG Embedded programming engine will decode. Once the embedded bitstream is obtained, it will be provided to the sysCONFIG Embedded software to configure the device.
While excellent support is offered for programming devices on PC and workstation platforms, many alternate platforms are in use. The best example is the use of embedded controllers and processors for programming. Many embedded configurations are in use, but these configurations vary greatly from project to project. Topics in this Help describe the sysCONFIG
Embedded software in detail to simplify modification for user-specific applications.
120
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
sysCONFIG Embedded Flow
The following figure illustrates sysCONFIG Embedded flow.
Programming Tools User Guide
sysCONFIG Embedded Bitstream Generation
You can use Deployment
Tool to generate sysCONFIG Embedded bitstreams for the current Lattice
FPGA device chain.
The chain must consist of a single Lattice FPGA device.
The device must have an input data file.
The device must be supported by the sysCONFIG Embedded software.
See the “sysCONFIG Embedded Device Support” topic in the Diamond
Programmer online help.
Parallel Mode and Serial Mode CPU Bitstream
For LatticeECP/EC and
LatticeECP2 devices, the Deployment Tool software can generate either a parallel configuration mode (PCM) CPU or a serial configuration mode (SCM)
CPU file depending on the operation type you have specified for the device in the Device Properties Dialog Box in Diamond Programmer. For example, if you have selected JTAG 1532 Mode under Device Access Options and Fast
Program under Operation, the CPU bitstream generator will output a parallel mode CPU file. If you selected Serial Mode and Serial Program in the
Device Information dialog box, a serial mode CPU file will be generated.
sysCONFIG Embedded Bitstream Options
There are several options to consider before generating the sysCONFIG
Embedded bitstream. You can set these options in the Deployment Tool Refer to Deployment Tool online help for more information.
Output Format
for generating the embedded bitstream: binary, C-code, and Intel hexadecimal. You can also generate a
CPU file in text format so that you can see all the commands, data, and the size of data shifting for debugging purpose.
Include Comments
Comments are decoded by the sysCONFIG Embedded engine and displayed to the terminal to inform you of the engine's actions.
This can be very helpful for debugging, but it increases the file size.
Compress Embedded Bitstream Files
This enables you to generate a compressed CPU bitstream file with smaller size and faster performance.
121
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
For Erase, Program, and Verify Operations, Skip the Verify Operation
You can skip the Verify operation while programming a device to reduce processing time.
Specify Values for the CFG Pins
The software allows you to specify the values of the CFG pins by using configuration mode. By default, selection of these values is disabled.
See Also
Generating a sysCONFIG Embedded Bitstream
sysCONFIG Embedded Basic Operation
sysCONFIG Embedded Bitstream
Format
The sysCONFIG Embedded software supports three embedded bitstream formats.
Binary. The binary format is used for the file-based sysCONFIG
Embedded. This allows you to call the sysCONFIG Embedded via command line and pass in the binary embedded bitstream as an argument. The file extension for this format is .cpu.
C-code. The C-code format is used for the compile-based sysCONFIG
Embedded. This format is an actual C programming language file that has the embedded bitstream expressed as an array. The file can be compiled with the compile-based sysCONFIG Embedded source code to generate an executable that has the embedded bitstream self-contained. The file extension for this format is .c.
Intel Hex. The Intel hexadecimal format is used for the function-based sysCONFIG Embedded. This format is a standard Intel hexadecimal that can be downloaded to the flash of the embedded system. A wrapper application may be developed to call the function-based sysCONFIG
Embedded and pass to it the embedded bitstream from the flash. This format contains an option to flip each byte of data prior to generating the file. By default, each byte is flipped. Depending on the user's implementation, it may not be necessary to flip the bytes. The file extension for this format is .hex.
Besides the above formats, you can also generate a CPU file in text format so that you can see all the commands, data, and the size of data shifting for debugging purpose.
See Also
sysCONFIG Embedded Bitstream Structure
Generating a sysCONFIG Embedded Bitstream
122
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
sysCONFIG Embedded Bitstream
Structure
The embedded bitstream is the driver behind the sysCONFIG Embedded software. It contains both instructions for the control pins and data for the data pins of the FPGA device. This method encapsulates the programming algorithm within the embedded bitstream, and generalizes the sysCONFIG
Embedded engine to increase versatility.
The following figure illustrates the algorithm and data contained in sysCONFIG Embedded bitstream.
Programming Tools User Guide
The algorithm section drives and verifies the control pins. A verification failure return code is issued if a pin fails to verify.
The original bitstream section contains the bitstream broken down by frames.
If the comment option was selected when generating the embedded bitstream
, comments are inserted before frames and displayed by the CPU engine to notify users the current frame being processed.
The entire embedded bitstream is protected by a CRC. Before the sysCONFIG Embedded software sends any data to the device, it calculates the CRC and verifies it against the CRC of the bitstream. If the verification fails, the software aborts with a CRC error code.
This CRC is referred to as the “soft” CRC, not to be confused with the CRC calculation that is performed internally by the FPGA device. See the figure below.
123
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
124
Example
The following embedded bitstream example shall perform the following:
1. Verify CRC.
2. Drive the PROGRAM pin high.
3. Send in pre-amble data 0x83 0xA7.
4. Issue the end byte command.
Embedded bitstream example:
0X08 0XFF 0XFF // 16-BIT CRC COMMAND
0X05 0X50 0X01 // DRIVE PROG_PIN HIGH
0X02 0X02 0X83 0XA7 // SEND PRE-AMBLE DATA
0X04 // END BYTE
sysCONFIG Embedded Basic Operation
The sysCONFIG Embedded is the software that will decode the sysCONFIG
Embedded bitstream and configure the FPGA device. It is available in three interfaces and two configuration modes.
sysCONFIG Embedded Interfaces
The sysCONFIG Embedded software is available in source code form and allows three possible interfaces.
File-Based Interface
The file-based interface expects the embedded bitstream in the binary format, with .cpu extension. This interface is ideal for simulating on PC. It allows you to call the software through command line and pass the binary embedded bitstream as the argument. Note that this assumes you have modified the source code to allow the program to interface to the device through a driver.
Compile-Based Interface
The compile-based interface expects the embedded bitstream in C-code format. This file shall be compiled along with the sysCONFIG Embedded source code to create an executable that has the
Programming Tools User Guide
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded data self-contained. This interface is ideal for programming on embedded systems.
Function-Based Interface
The function-based interface expects the embedded bitstream in Intel hexadecimal format. This file shall be stored in the flash or PROM of the embedded system for later use. Unlike the filebased and compile-based approach, the interface to the sysCONFIG
Embedded engine in this interface is through a function. The arguments to the function shall be a pointer to the embedded bitstream residing in the flash and the size of the embedded bitstream.
sysCONFIG Embedded Configuration Modes
For LatticeECP/EC and LatticeECP2 devices, the software can generate either a parallel configuration mode (PCM) CPU or a serial configuration mode (SCM) CPU file depending on the operation type you have specified for the device in the Device Properties dialog box. For example, if you have selected JTAG 1532 Mode under Device Access Options and Fast Program under Operation, the CPU bitstream generator will output a parallel mode
CPU file. If you selected Serial Mode and Serial Program in the Device
Information dialog box, a serial configuration mode CPU file will be generated.
Parallel Configuration Mode (PCM)
The parallel programming engine reads the CPU format files generated by Deployment Tool and manipulates the I/O port. The engine requires the I/O system to be connected to the parallel programming port of the device. For Lattice devices this is the sysCONFIG parallel port.
Serial Configuration Mode (SCM)
The serial programming engine manipulates the I/O port. It requires the I/O system to be connected to the serial programming port of the device. For Lattice devices this is the sysCONFIG DI/DO port.
See Also
sysCONFIG Embedded Source Code
sysCONFIG Embedded source code is developed using ANSI C to ease portability among the many different platforms. The source code files can be found in the
<install_path>\<version_number>\embedded_source\cpuembedded directory. The following lists the available source code files.
main_f.c
main_e.c
main_tag.c
cpu_core.c
cpu_hard.c
cpu_sim.c
cpu_code.h
125
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
There are five components to the sysCONFIG Embedded source code: main, engine, hardware, simulator, and definition.
Main
There are three different main files depending on whether you want to use the file-based, compile-based, or function-based interface . Each interface is available in main_f.c, main_e.c, and main_tag.c, respectively. When using the compile-based interface, the embedded bitstream must be generated as
C-code and compiled with the rest of the source code.
Engine
The
can be found in the
cpu_core.c file. This file is responsible for decoding and executing the embedded bitstream. You should not modify this file.
Hardware
The hardware related functions can be found in the cpu_hard.c file. This file is responsible for writing to and reading from the ports that connect to the device. You may modify sections of this file to target specific hardware. These sections are preceded by the comment “Note: user must re-implement to target specific hardware”
to alert you that it requires modification. If you include this file, you will have to remove the cpu_sim.c file from your project. These two files are not compatible.
Simulator
The simulation function could be found in the cpu_sim.c file.
This file is used for generating an output file with the resultant code. This could be done if you want to simply compare outputs without having a device plugged in. The simulator will take the following argument: “.cpu file
<output file>”
. If you use this file, remove the cpu_hard.c file from your project.
Definitions
The definitions for the embedded bitstream, sysCONFIG
Embedded engine, and return codes can be found in the cpu_code.h file.
You should not modify this file.
126
sysCONFIG Embedded Engine
The sysCONFIG Embedded software brings sysCONFIG port programming capability to Lattice Semiconductor's suite of FPGA devices on embedded systems. The software offers a unique virtual programming engine that can support the different programming algorithms of each device family.
The sysCONFIG Embedded engine is based on the sysCONFIG Embedded bitstream. It processes the bitstream until the END_BYTE_COMMAND or an error is encountered and returns with an appropriate return code.
The sysCONFIG Embedded engine supports the following different run operations generated from Deployment Tool:
Erase, Program, Verify
Erase, Program, Verify, and Secure
Erase Only
Verify Only
Verify ID
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
SRAM Program, Verify
SRAM Verify Only
XSRAM Verify Only
The sysCONFIG Embedded engine has three layers as follows:
User interface layer (cpu_main.c) – Directs inputs and outputs.
Processor layer (cpu_core.c) – Decodes commands, checks CRC prior to processing, and does optional decompression.
Physical layer (cpu_hard.c) – Shifts data to target device. This is the only file that you need to edit.
The following figures illustrate sysCONFIG Embedded sysCONFIG port programming engine in parallel and serial configuration modes.
Parallel Configuration Mode.
Programming Tools User Guide
127
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
Serial Configuration Mode.
File Based
(Bitstream File External)
PROM Based
(Bitstream File Integrated)
Sample Program Size
This page provides sample program size for JTAG Full VME Embedded,
JTAG Slim VME Embedded, and sysCONFIG Embedded.
JTAG Port
JTAG Full VME
Embedded
JTAG Slim
VME
Embedded
32-Bit
52KB
16-Bit
21KB
8-Bit
4.2KB
non-JTAG Port sysCONFIG
Embedded
32-Bit
48KB
16-Bit
19KB
Total
As Shown
52KB 21KB 4.2KB
48KB 19KB As Shown +
VME File Size
128
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
Programming Tools User Guide
Generating a sysCONFIG Embedded
Bitstream
You can generate sysCONFIG Embedded bitstream using the Deployment
Tool for programming sysCONFIG Embedded supported devices .
For LatticeECP/EC and LatticeECP2 devices, the Deployment Tool can generate either a parallel programming mode CPU or a serial programming mode CPU file depending on the operation type you have specified for the device in the Device Properties Dialog Box in Diamond Programmer. For example, if you have selected JTAG 1532 Mode under Device Access
Options and Fast Program under Operation, the CPU generator will output a parallel programming mode CPU file. If you selected Serial Mode and Serial
Program in the Device Properties dialog box in Programmer, a serial programming mode CPU file will be generated.
There are two important options to consider when generating the embedded bitstream. The first option is whether or not to generate the file with built-in comments. These comments are decoded by the sysCONFIG Embedded
129
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded engine and displayed to the terminal to inform the engine's actions. This is helpful for debugging purposes, but the file size will increase slightly.
The second, and more important, option to consider is which of the three
formats should the embedded bitstream be generated with. See sysCONFIG
for details.
See Also
sysCONFIG SPI Port AC Parameters
The board layout and waveform diagrams are shown here to illustrate when the configuration AC parameters can be characterized for the following configuration modes:
SPI (Serial Peripheral Interface)
PCM (Parallel Configuration Mode)
SCM (Serial Configuration Mode)
SPI (Serial Peripheral Interface)
Board Layout.
130
Programming Tools User Guide
Waveform
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
PCM (Parallel Configuration Mode)
Board Layout
Programming Tools User Guide
Waveform
131
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
132
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
SCM (Serial Configuration Mode)
Board Layout
Waveform
Programming Tools User Guide
sysCONFIG Interface
This page provides interface diagrams and description on the following CPU sysCONFIG solutions.
CPU programming solution
The SRAM fuses in LatticeXP and LatticeECP/EC and the FLASH fuses in LatticeXP can be programmed by using the sysCONFIG port connected to a CPU. This page will describe SRAM fuse programming and present a
66MHz programming solution for LatticeECP/EC devices.
133
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
If both the DONE pin and the INIT pin are high after programming, or refresh, the device then must be programmed successfully.
Note
Only if the FLASH DONE fuse is programmed can the FLASH pattern be downloaded into the SRAM fuses of the device. If the FLASH DONE fuse is not programmed, the download is blocked. FLASH DONE fuse is the last fuse to be downloaded from FLASH to SRAM. The FLASH is downloaded to SRAM in a protected and shielded environment and therefore it is not subject to the effect of external noise or ground bounce which is the common problem when downloading from external FLASH memory devices. The DONE pin is a very reliable indicator on the programming status. This renders the readback un-necessary.
CPU read back solution
The SRAM fuses in LatticeXP and LatticeECP/EC and the FLASH fuses in LatticeXP can be read back by using the sysCONFIG port connected to a CPU. This page will describe SRAM fuse read back and present CPU read back solution for LatticeECP/EC devices.
Read back of SRAM fuses is presented here for completeness. There is very little to gain on actually performing read back.
Read back of SRAM fuses can only be done when the following conditions are met:
The device has already been programmed successfully;
The device has already waken-up and is in user mode;
All EBR data must be ignored;
All distributed RAM data must be ignored.
Note
Only the JTAG port of the device supports readback in both user mode and programming mode. If the device has not yet been programmed successfully, it will not respond to the READ_INC command sent to it on the sysCONFIG port.
Subjects included in this page:
CPU Interface Basic
The Bitstream Format
CPU Parallel Programming Interface
CPU Serial Programming Interface
CPU Byte-Wide Programming Flow
CPU Byte-Wide Read back Flow
CPU Bit-Wide Programming Flow
CPU Interface Basic
Lattice's CPU interface supports the command, operand, and data bitstream format.
134
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
The Bitstream Format
Bitstream Type
Preamble Code
Command
Data IDCODE
Config.
CRC
Usercode
Bitstream Orientation
D0..D7,D0..D7...
Data (Binary)
Bit[15..0]
1011110110110011
Bit[31..0]
Bit[0..31]
Control Register Bit[0..31]
Bit[N-1..0]
Bit[0..16]
Bit[0..31]
Bit[31..24] = Opcode;
Bit[23..0] = Command
Information
Bit[0..31] = IDCODE
Bit[0..31] = Control Register
Configuration Data
Bit[0..16] = CRC
Bit[0..31] = Usercode
Data (Hex)
BDB3
ECP-20-IDCODE=C20A2480
Programming Tools User Guide
135
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
Command
RESET_ADDRESS
CLEAR ALL
WRITE_INC
READ_INC
32-bit Command
Bit 31...24
Bit 23...0
Opcode Operand
hE2 hF0 hC1 h81
Don't Care
Don't Care
Write
X
X
# Of Frames X
# Of Frames X
Read
X
X
Description
Set address to row 0 (first row).
Clear all SRAM fuses.
Program a frame then increment the row address.
Read a frame then increment the row address.
WRITE_USERCODE hC3
READ_USERCODE h83
WRITE CTRL 0 hC4
Don't Care
Don't Care
Don't Care
X
X
X
X
READ CTRL 0
PROGRAM_DONE /
END_READ
READ_IDCODE
VERIFY_IDCODE
BYPASS
FLOW_THROUGH
NOOP h84
PROGRAM_SECURIT
Y hF3 hFA h87 hC7 hFC hFD hFF
Don't Care
Don't Care
Don't Care
Don't Care
Don't Care
Don't Care
Don't Care
None
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Program 32 bits usercode
Read out 32 bits usercode.
Program the 32 bits program flow control register 0.
Read out from the 32 bits control register 0.
Program the security fuses to disable readback.
Terminate the programming or readback flow.
Read out the 32 bits JTAG IDCODE of the device.
Compare the 32 bits data against the 32 bits
JTAG IDCODE.
Send data to Dout for the next device in chain.
Drive CSO low to select the next device in chain.
Put a device in a wait state for extra delay.
Bit 31 of the opcode determines if the command and data is included in CRC.
The opcode shown does not select CRC inclusion. The bitstream generated by the Diamond software makes that decision automatically. The read command is not recommended to include CRC.
136
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
CPU Parallel Programming Interface
Only four pins, PROGRAMN, INITN, DONE, and CCLK, are dedicated. The other pins are dual purpose pins. The DI pin has no function on parallel programming.
CPU Serial Programming Interface
Programming Tools User Guide
Only four pins, PROGRAMN, INITN, DONE, and CCLK, are dedicated. The other pins are dual purpose pins. Only the DI pin and DOUT/CSO pin are used on serial programming.
137
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
CPU Read back Interface
138
Only four pins, PROGRAMN, INITN, DONE, and CCLK, are dedicated. The other pins are dual purpose pins. The read back is turned on by selecting the
Persistent On option when generating the bitstream.
The DI pin has no function on read back. Same as other dual purpose pins, it cannot be recovered as user IO if read back is selected.
The PROGRAMN pin must be left alone during read back. Pulsing it will terminate the read back immediately and start re-configuration.
The device responds to read back command only if it has already been configured successfully.
CPU Byte-Wide Programming Flow
Below is the CPU byte-wide programming flow:
1. Toggle PROGRAMN pin to set the devices into programming mode.
2. Wait 1 microsecond then check if the DONE pin is low. If it is low then continue. If it is high then report failure.
3. Pulse several clocks on CCLK to make sure the devices are ready.
4. Wait 20ms then check INIT pin. If it is high, then continue.
5. Drive CSN, CS1N and WRITEN to low to activate the byte-wide D[0..7] interface to receive data.
6. Send the first byte bit[7..0] from the bitstream file to D[0..7] then pulse the clock to clock it in.
7. Repeat step 6 till the whole bitstream file is sent to the device.
Programming is then complete.
8. Check if INIT pin is high. If it is high then continue. If it is low, then report failure.
9. Pulse 100 clocks on CCLK to ensure the devices are waking up.
10. Check if the DONE pin is high. If it is high, then programming is successful. If it is low, then report failure.
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
11. Drive CSN, CS1N, WRITEN back to high to terminate.
Note
1. The device captures data on the rising edge of CCLK.
2. The maximum rate sending data to the device is 66MHz.
3. The bitstream file could be for one device or merged for two or more devices.
Board Layout
Waveform
Programming Tools User Guide
CPU Byte-Wide Read back Flow
Below is the CPU byte-wide read back flow. Before performing CPU byte-wide read back, the persistent fuse must be programmed already to enable reading.
1. Check if both DONE and INITN pins are high. If they are high then continue. If not then report failure.
2. Drive WRITEN, CSN, and CS1N to low to enable the D[0..7] interface to receive command.
139
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
3. Write several bytes of 0xFF to D[0..7] and clock them into the device to clear the bus.
4. Write the pre-amble code 0xBD, 0xB3 and clock them into the device to enable the command decoder.
5. Write the READ_IDCODE command 0x87 to D[0..7] and clock them into the device then follow with 3 bytes of 0x00 as operand. Reading IDCODE is necessary to ensure communication is established with the device.
6. Drive CSN from low to high (or CS1N, not both) then drive WRITEN from low to high. Pulse one clock on CCLK to change D[0..7] from input port to output port.
7. Drive CSN back from high to low (or CS1N if it was driven high at step 6).
Pulse one clock on CCLK to present one byte of data on D[0..7].
8. The BUSY pin tracks the CSN (or CS1N) pin. The data on D[0..7] is not valid when it is high.
9. Read the first byte of the IDCODE from the D[0..7] of the first byte bit[0..7] of the JTAG IDCODE.
10. Pulse CCLK then read the next byte bit[8..15] of the JTAG IDCODE.
11. Repeat step 10 till bit[16..23] then bit[24..31] is read from D[0..7].
12. Compare the 32 bits IDCODE read from the device against the expected
IDCODE of the device. If they match, then continue. If not, then report error.
13. Repeat Step 5 to 11 to read the USERCODE. The READ_USERCODE opcode is 0x83. It is a good practice to put the fuse checksum on usercode to indicate that the device has been programmed correctly to the pattern when reading back.
14. Drive CSN from low to high then drive WRITEN from high to low. Pulse one clock on CCLK to change D[0..7] back to an input port.
15. Drive the first byte of the RESET_ADDRESS command, 0xE2, to D[0..7].
Pulse one clock on CCLK for the device to read it in.
16. Drive D[0..7] and clock CCLK to send 3 bytes of 0x00 as dummy operands to the device. The address of the device is now set to the first frame.
17. Drive the first byte of the READ_INC command, 0x81, to D[0..7]. Pulse one clock on CCLK for the device to read it in.
18. Drive to D[0..7] and clock CCLK the number of frames to be read from the device expressed in 24 bits hex number, or 3 bytes.
Example: If read 3 frames, then 3 bytes of operand is 0x00, 0x00, 0x03. If read 256 frames, then 3 bytes of operand is 0x00, 0x01, 0x00.
Note
The number must not be larger than the maximum number of frames in the device.
19. Drive CSN from low to high then drive WRITEN from low to high, then pulse CCLK to set D[0..7] up as an output port.
140
Programming Tools User Guide
Programming Tools User Guide
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
20. Drive CSN from high to low then pulse CCLK for the device to drive the first byte from the first frame to D[0..7].
21. Pulse CCLK then read the next byte till all the bytes in the first frame are read. The device will increment the address automatically when all bytes in the current frame are read.
22. Continue to pulse CCLK till all the frames or up to what is specific on the operand sent to the device at step 18.
Note
Do not read beyond that number, otherwise the device will drive INIT low to indicate over-read.
23. Drive CSN from low to high then drive WRITEN from high to low. Pulse one clock on CCLK to change D[0..7] back to an input port.
24. Drive the opcode, 0xFA, of the END_READ command to D[0..7]. Pulse
CCLK for the device to read it in.
25. Drive 0x00 to D[0..7] then pulse CCLK 3 times as the dummy operand to complete the command. Read back is then terminated.
26. Drive CSN, CS1N, and WRITEN back to high to disconnect the sysCONFIG port of the device.
Note
1. If the command is under shift, then the device will enter error state.
2. If the command is over shift, then the device will also enter error state.
3. If the data is under shift, there is no error state.
4. If the data is over shift, dummy data is presented to D[0..7]. The device will not enter error state.
5. Driving both CSN and CS1N to high will reset the device.
6. The read back clock frequency is much slower than 66MHZ due to the time required to switch the polarity of D[0..7] from input to output.
7. The data is shift out from the device on the rising edge of CCLK.
8. If the security fuse is programmed, the usercode and JTAG IDCODE still can be readback.
9. The opcode sent to the device for reading purpose are not recommended to include CRC. Hence bit7 of the opcode is 1.
10. The number of frames put on the operand must be less than or equal to the number of frames the device actually has.
11. If the number exceeds the actual number of frames, the device will enter error state.
CPU Bit-Wide Programming Flow
Below is the CPU bit-wide programming flow:
1. Toggle PROGRAMN pin to set the devices into programming mode.
2. Wait 1 microsecond then check if the DONE pin is low. If it is low then continue. If it is high then report failure.
141
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
3. Pulse several clocks on CCLK to make sure the devices are ready.
4. Wait 20ms then check INITN pin. If it is high, then continue.
5. Drive bit7 of the first byte from the bitstream to DI then pulse the clock to clock it in.
6. Repeat step 5 till bit6..0 of the first byte is sent.
7. Repeat step 6 till the whole bitstream file is sent to the device.
Programming is then complete.
8. Check if INIT pin is high. If it is high then continue. If it is low, then report failure.
9. Pulse 100 clocks on CCLK to ensure the devices are waking up.
10. Check if the DONE pin is high. If it is high, then programming is successful. If it is low, then report failure.
Note
1. The device captures data on the rising edge of CCLK.
2. The maximum rate sending data to the device is 66MHz.
3. The bitstream file could be for one device or merged for two or more devices.
Board Layout
142
Programming Tools User Guide
Waveform
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
Programming Tools User Guide
143
E
MBEDDED
F
LOW
O
VERVIEW
:
sysCONFIG Embedded
144
Programming Tools User Guide
Numerics
8051
using the 8051-based slim ispVME 76
B
bitstream
generating CPU embedded bitstream 129
C
CPU Embedded
D
device programming
E
Embedded System
RAM size requirement for ispVME 37
ROM size requirement for ispVME 39
Embedded, JTAG, Full VME 19, 30
Embedded, JTAG, Slim VME 19, 73
F
file generation
file processing
file size
FPGA
generating a CPU embedded bitstream 129
Full VME Embedded, JTAG 19, 30
G
generating
I
ispVM Embedded
RAM size requirement for ispVME 37
ROM size requirement for ispVME 39
ispVME
J
Programming Tools User Guide
145
M
P
processing
program memory allocation 41 program memory requirement 41
Programmer
programming devices
programming engine
R
RAM size requirement for ispVME 37
resource requirements
program memory 41 program memory allocation 41
ROM size requirement for ispVME 39
S
slim ispVME
using the 8051-based slim ispVME 76
using the PC-based slim ispVME 75
Slim VME Embedded, JTAG 19, 73
source code
U
using
PC-based slim ispVME 75 slim ispVM Embedded System 75
V
VME
algorithm format - slim ispVME 76
146
Programming Tools User Guide
advertisement
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Related manuals
advertisement