LCA loads own Configuration ROM

DISCLAIMER
This information is provided strictly "as-is", and the author accepts no liability of any kind for events which may result from its use. No warranty of any kind is made regarding perfomance, freedom from faults, etc.

Note: The drawings comprising this design can be downloaded in the following formats:

Other downloads available:

List of figures:

Fig. 1 Example board-level schematic
Fig. 2 ROM-loader FPGA (sheet 1)
Fig. 3 ROM-loader FPGA (sheet 2)
Fig. 4 Address counter
Fig. 5 Example waveforms

INTRODUCTION

This page describes a method of using a Xilinx 4000-series FPGA to initialise its own configuration memory (a flash ROM). Since the TAP port is used, a minimum of FPGA resources are taken up by this function. The example design includes a CPU, however this is not necessary for loading. With the flash ROM loaded, the FPGA may self-configure in the normal way.
Although the example design also includes a CPU, this could not be used to initialise the ROM, since it requires the FPGA to function. In use therefore, the FPGA takes control after reset, and self-configures before allowing the CPU to run.

From a viewpoint strictly of initialising the ROM, the CPU merely adds complexity, requiring to be isolated from the bus. With the Zilog CPU used in the example, a Reset will 3-state the address and data lines. However the Read and Write strobes, and the ROM chip enable must still be isolated by extra circuitry. In the example, this circuitry was embodied in the FPGA, however external buffers or multiplexers could be used, with a low level on the FPGA INIT line serving to indicate that external loading is in progress.

OPERATION

The circuitry external to the FPGA is shown in Fig. 1. Note that this drawing is stored oversize, to ensure detail is accurately reproduced.

The programming circuitry is at the bottom of the drawing, and comprises the latch U8 and buffer U9. If desired, these could be put on a separate "loader" board, to reduce cost in the main PCB. The signals required at the connector would be

TCK
TMS
TDI
TDO
PGM\
DONE
INIT

To initialise a blank board, the programming connector P1 is attached to a PC parallel port. The D0..D5 printer lines carry signals to the board, with data returned on the ACK and BUSY lines.

**PIN ASSIGNMENTS**
Pin	Name	Function	Notes
2	D0	TCK LOW\	Pulse low to set TCK low
3	D1	TCK HIGH\	Pulse low to set TCK high
4	D2	INIT\	Used to reset the FPGA
5	D3	PGM (ie Reset)	Used to reset the FPGA
6	D4	TMS	TAP line: mode control
7	D5	TDI	TAP line: data to FPGA
10	ACK	TDO	TAP line: data from FPGA
11	BUSY	DONE	Signal from FPGA

When no PC is attached, the lines are pulled up by U10, which leaves PGM\ high and INIT 3-stated. Given an external pulse at PORST\ (from the power supply), the FPGA executes a normal start-up. Since the M0..M2 pins are wired to start the FPGA in Master Parallel mode, it self-loads from the ROM. During this time the HDC output is high, which holds the CPU in reset. This (in Zilog CPUs) 3-states the address and data pins. The RD\ and WR\ strobes however are not 3-stated, and are therefore buffered through the FPGA (an external 3-state buffer could have been used). This ensures that all memory lines may be driven by the FPGA without contention issues arising.

The FPGA issues ROM addresses, and drives RD/BS\ low to read the ROM. For this reason, RD/BS\ was chosen to output the CPU's read-strobe, since it exhibits the proper behaviour during configuration. The ROM chip-select is fed from LDC for a similar reason.
Since Zilog CPUs boot from low memory, the FPGA code is stored downward from the top.

Once configuration is complete, HDC falls, so causing the CPU reset line to go high. At this point the CPU commences running code, with the FPGA fully configured. The configuration should include paths from the CPU's RD\ and WR\ strobes to the RS\ and WS\ outputs (since these lines were intercepted by the FPGA).

Since both ROM and RAM chip-selects are buffered through the FPGA (so they can be controlled during configuration), means are included to access both devices via the TAP port, to aid testing.

PROGRAMMING

To initialise the ROM, a PC parallel port is connected to P1. When the programming software is started, it asserts PGM\ and drives INIT low. This forces a reset at the FPGA, which in turn forces the CPU off the bus.

The program now releases PGM\, while holding INIT low to prevent the FPGA from starting its configuration sequence. The TAP port is now accessible, by clocking TCK. Note the latch U8 to generate TCK: some PC parallel ports are rather noisy (especially at the end of a long cable), and this latch prevents problems due to TCK double-clocking.

INITIAL CONFIGURATION

Initialisation commences by shifting a "configure" command into the FPGA, followed by the configuration file. This procedure is described in the Xilinx documentation, and will not be repeated here. The configuration file, "CONFIG.MCS" (archived with the software) implements the circuit of Fig. 2, which comprises a shift register for data, an address counter, and a state machine, coded in ABEL . An example of operation is shown in Fig. 5, which is the output of a ViewLogic simulation.
The TAP port commences by outputting a 2-bit command code (the bits C1 and C2 on the drawing). The C1 bit is tagged by setting TMS Low.
The functions available are:

C1	C2	Function
0	0	Shift TAP data to address counter
0	1	Increment address counter
1	0	Read ROM to data register, & shift to TAP port
1	1	Shift TAP data to data register, & write to ROM

The read and write strobes are each 1 TCK clock wide: the actual width being controlled by the host, which generates the TCK clock.
Data is clocked into the FPGA on the rising edge of TCK, and clocked into the host on the falling edge (this complies with the JTAG/TAP specification). Every command commences with a 1-clock Low on the TMS line: the state machine will idle indefinitely between commands while TMS remains High. The 4 functions are illustrated as follows:

Shift TAP data to address counter

Following the command bits, a ROM/RAM select bit is passed, followed by a 17-bit address, most significant bit first. When the last bit has been shifted, the state machine is reset, expecting a new command.

Increment address counter

After the command bits, 2 further clocks are sent, to allow the operation to complete.

Shift TAP data to data register, & write to ROM

The data is sent (most significant first) immediately after the command bits. 2 further clocks follow, to allow the function to complete (the first idle clock is mandatory: more are optional).

Read ROM to data register, & shift to TAP port

The first data bit becomes available to the host 1 clock after the C2 bit is sent. As normal, bits are clocked most significant first.

HOST SOFTWARE

The programming software is downloadable as a compressed archive. The source-code is C++ and Intel assembler, compiled via Borland Turbo C++, V3.0.

The software is designed to allow new ROM devices (which require different programming algorithms) to be readily included, by adding new part classes, derived from the flash-ROM base class. The code supplied includes a well-used module for Intel 12V parts, and an experimental Atmel module.

SETTING UP

The loader program is ready for use. Place the files LOADER.EXE and CONFIG.MCS (both from the software archive) in a single directory.
Connect the target board to a parallel port (bi-directional support is not necessary), and supply power.

Execute
LOADER 'MY_CONFIGURATION_FILE'
citing the file holding your target FPGA configuration. The program will ask what parallel port is used, and will then check that a FPGA is connected.
Next the program will ask what board hardware you are using, "reader" or "tag". This question is of historical significance only: the correct response (for the schematic shown here) is "Tag".
The FPGA will be configured, and you will be asked to supply an address offset which will be added to the addresses in your configuration-data file, to obtain the ROM addresses. This is necessary to load at addresses above 65kB, as the Xilinx software only handles 16-bit addresses.
A check is made that the area to be programmed is blank: if not, you will be asked to authorize erasing the ROM. Programming will then commence. Be aware that the Intel erasure algorithm permits up to 1000 re-tries: do not be alarmed to see the retry count rising to large numbers.

When programming is complete, you will be asked whether to shut down the system, or if the programmer should issue a local reset to your target board. If you select this, the TAP interface will fake a power-on reset to your board, and the configuration you have just downloaded will receive control.

Back to Home Page