UART and Testing Accelerators

This week had a lot of testing going.

First of all UART is 90% done. It has been tested by simulation and on FPGA communicating with the PC through Minicom. I’ve faced a very interesting issue while testing UART on Spartan 6 ATLYS board.

My UART can transmit data to the PC but it doesn’t seem to be receiving any data sent by the PC except when I send a Break Signal. I’ve tried slowing down the PCs Baud Rate, altering the flow control on Minicom, sending the Null character ( which is basically a break signal) and even using different PC and different communication software like Cutecom and GTKTerm but all went in vain and I couldn’t solve the problem. I then switched to Spartan 3A start up board and to my surprise my same design worked perfectly with the same PC. It’s worth mentioning that the Spartan 3A is identified by the Linux as ttyUSB0 while ATLYS board is identified as ttyACM0. While this article tries to explain the difference between them I didn’t really have time to stop and analyze the situation. Thus I’m only left with an educated guess that the problem has to be somewhere either in the driver of the ATLYS UART on Linux or in the IC providing the UART signals to the FPGA. I have no clue whether this problem is limited to my Board or it’s across the whole ATLYS product line.

During my troubleshooting I came to notice that on the ATLYS board when the JP11 Jumper is set LED7 stays on. It turned out that this is no fault as explained here and as confirmed by the ATLYS board schematics, this LED is supposed to remain on.

As for testing Accelerators, I’ve tested RC4 slow and fast cores this week. I’ve discovered a bug with RC4 both cores when communicating with Wishbone. Somehow the core assumes a burst transaction with the wishbone bus with the STB line remaining high during the whole transaction. This is not the case with the AEMB wishbone transactions and a fix was devised for this bug. Moreoever I tested ECDSA core. The three cores worked flawlessly by simulation run by their corresponding drivers. Nonetheless, when it came to FPGA implementation only the slow version of RC4 performed as expected. Each of the cores is tested through being run by the AEMB processor and displaying it’s output on the LEDs through the GPIO. The other two cores need further troubleshooting to identify whether it’s the cores problem or a random error in my simple SOC.

Next week I’m designing an I2C core.