Close

Programmer Protocol

A project log for TinyFPGA Programmer

A dirt cheap open hardware USB-JTAG board designed to program TinyFPGA A1 and A2 boards.

luke-valentyLuke Valenty 08/19/2017 at 16:450 Comments

From the TinyFPGA Programmer GitHub:

Serial Protocol

The programmer firmware appears as a generic USB serial port when you connect it to a computer. Control of the GPIO pins on the programmer is through this simple serial interface.

Command Format

Commands are encoded as 8-bit bytes with a command type field and data payload. The payload is typically a 6-bit bitmap representing the GPIO pins of the programmer.

7:6543210
Command TypeTMSTCKTDITDORC1RC0

Commands

OpcodeCommand
0Configure Input/Output
1Extended Command (Unused)
2Set Outputs
3Set Outputs and Sample Inputs

Configure Input/Output

For each of the GPIO pins, set the direction of the pin.

Extended Command

Reserved for future command expansion.

Set Outputs

Set each of the output pins to the given values.

Set Outputs and Sample Inputs

Set each of the output pins to the given values and return a byte representing the current values of the input pins.

General Usage

For serial interfaces like JTAG this protocol divides the maximum possible bandwidth by 8 from the USB to JTAG interface. This means we might get 0.5MHz JTAG programming speed. That speed is actually fast enough to transfer all the data to the FPGA in a few seconds. However the configuration flash on the FPGA actually needs a fair bit of time after erase and write operations that will slow down the programming operatuon.

What can really slow down programming is the turnaround time for reading back data from the FPGA. For the most part data is going in one direction from the host computer to the programmer to the FPGA. For these cases we can use the Set Outputs command and not wait for any data to return. However there are times when we may need to poll a status bit to see if the FPGA has finished an erase or write operation. In this cases we will want to also sample the inputs and check the status. These should not be timing sensitive because the FPGA is already busy.

Verifying the configuration data on the other hand could take a long time if not done carefully. The application talking to the programmer should make sure to write as many commands as it can before attempting to read back the data from the serial interface. Rather than paying a penalty for the turnaround time on every read bit, we pay for it after reading dozens of bytes. This should allow read-back of the configuration data to be relatively quick and painless.

Discussions