Testing the FPGA

Started the week by checking some of the keyboard code to find out what is wrong. I found that the device driver for the keyboard seem to be working ok, just the key sending part. The code seems to be for a keyboard with a 6 key rollover, which lets the keyboard send multiple keys at one go. I removed some part of the rollover code and as expected, it won’t send any keys, but the device driver works fine meaning my computer detects the device as a keyboard, also it has stopped jamming up my computer keys.

Moving on from the keyboard, I started testing out the FPGA code created by the previous interns, as the digital pins do not toggle as expected after the FPGA has been configured, but instead goes into a ground state. In the beginning both PROGRAM_B and INIT_B pins are high, initializing the FPGA involves driving the PROGRAM_B pin low and waiting for the INIT_B pin to be driven low by the FPGA, after that the PROGRAM_b pin is driven high by the pic32mz and it waits for the FPGA to drive the INIT_B pin high, this is like a handshake between the pic32mz(master) and FPGA(slave) to let it know that the FPGA is ready for programming. This process is difficult to capture using sigrok pulseview as the process happens so fast that the sampling rate used is not enough to capture these changes.

I  modified the code which before this, uses a delay in the process of driving the PROGRAM_B pin low then high, to a using a while loop that runs until it receives a confirmation from the FPGA before proceeding to the next step. Using the while loop enables the FPGA to reset everytime the board is reprogrammed, which it didn’t do before. The while loop also enables the handshake to be delayed sufficiently for the process to be captured using Pulseview, with a pulse sent by the FPGA lasting only about 0.5 microseconds so a sampling frequency about 4MHz and above is recommended.

There are 4 spi modes with CKP,CKE of 0,0 or 0,1 or 1,0 or 1,1. CKP is the clock polarity which controls whether the idle state of the clock is lo or hi, and CKE is associated with the clock edge, rise or fall. Tests show that the FPGA will only load when CKP,CKE is 0,0 or 1,0 or 1,1. Next step was to check if the bit endian was the wrong way around, a c program was created to flip the bits in each byte. Testing using the hex array with the bit flipped, the FPGA does not configure with the DONE pin still low at the end. I did additional tests flipping the bytes and also bits+bytes and as expected, it doesn’t load. I then checked with the DONE pin and indeed it follows the Serial Configuration Data Timing in ug380.pdf with the done pin low initially and then set high after successful configuration.

Then I proceeded to check if the clock supplied to the FPGA is correct. Finding out which pin is the clock pin is easy, you can check the UCF file or check ug385.pdf which contains the pinouts for the Spartan 6 FPGA, then checking with the board schematics. The tricky bit is testing the pin as it theoretically runs at 100MHz compared to the 24MHz sampling using Pulseview, And also in Harmony configurator the pin is fixed. After checking through the code I found that the clock frequency probably controlled under the Harmony Framework Configuration->Drivers->SPI->SPI Drivers Instance 0->Clock to use, the frequencies of the respective peripheral bus clock stated in Harmony Framework Configuration->System Services->Clock->Use Clock System Service?->Clock Configurator Settings->Calculated Clock Frequencies. I tested the clock pin with different frequencies which indeed give different voltage readings, which means the clock pin is altered according to this configuration. The frequency used is indeed set at 100MHz.

Some things to take note of, I used Sigrok Pulseview with my Windows pc, the drivers for the USBee AX PRO mini logic analyzer may not be installed. Go to download pulseview-NIGHTLY-installer.exe, install it and then run Zadig which comes with the installation to install the driver. Now when you run Pulseview it should auto detect the device, if it doesn’t then just go to select Connect to Device, choose fx2lafw as the driver then scan for the device and it should pop up.

You may also like...

Leave a Reply