# Having trouble synchronizing serial data from FPGA to python script

I have a Spartan 6 that's collecting some data I need to send over serial to a python script where it can be displayed on my PC.

This is actually the first time I've ever dug into serial communications (I don't count programming arduinos)

So I'm essentially specifying the data format myself from the FPGA which makes me think I should easily be able to sync this communication, but it seems a little more difficult than I thought.

This is my current approach:

The data I am sending is 16 bits long, and I assumed that I needed to send the start/stop bits manually, so my serial VHDL module just reads in the 16 bit value and concatenates like this:

output_vector <= '1' & din & '1'


From there, a counter just loops from 0 to 17, assigning the Tx line to the current index of the output_vector

So I am not sure if my assumption is correct here. Do the start and stop bits need to be manually transmitted like this? And how does the receiving end know a start/stop 1 from any other 1 in the data signal?

Baud rate

The counter I mentioned previously cycles through at a rate of 195.3125 kHz, so I added 16 bits for data + 2 start/stop bits = 18 bits total.

195312.5 / 18 = 10,850.694444444

So in my python script, I set the baud rate to 10,851 as that is the nearest integer value. Even so, I don't understand how the receiving end synchronizes up with the transmitting side so it is actually in line and gets correct data.

My python script is pretty simple:

import serial

def convert_to_ascii(text):
return " ".join(str(ord(char)) for char in text)

ser = serial.Serial(12)
ser.baudrate = 10851

print ser.name

while(True):

print(convert_to_ascii(data))


I ultimately need some way of combining the 2 bytes being read into 1 single integer value, but I haven't quite figured that out yet either. The script is receiving data, but I cannot verify it is correct at all.

There is also mention of some sort of Xon/Xoff transmission relating to software flow control in the user guide for my FPGA board (Digilent Nexys 3), but I really have no idea how to use that. I'm totally lost here on how to synchronize up this simple serial connection.

Simply put, you're not transmitting valid UART serial.

Serial comprises of one start bit, 7 or 8 data bits, 1 or 0 parity bits, and a stop bit.

In total that's 10 bits. The most common arrangement of that is 1 start, 8 data, and 1 stop.

Note that the UART has an "idle" state - HIGH in this case. The start bit is the opposite of the idle level, and the stop bit returns you to that level. The receiver waits for the transition from idle to not idle to know when it's starting to receive.

To transmit 16 bits of data you have to transmit it as two separate bytes. That would be 1 start, 8 data, 1 stop, 1 start, 8 data, and 1 stop. That's a total of 20 bits.

The baud rate is the number of symbols per second - that is the number of 1 or 0 bits, not the number of whole packets. So if you are shifting the data out at 195312.5Hz then the baud rate is 195312.5

Of course you now need a way of knowing which of your bytes are which - and now you are into the realms of data packets, and higher level protocols.

• So I have read that baud rate is the number of symbols/sec. In my case then, despite the fact that each value is 8 bits, there is still only 1 symbol per bit? I guess I was thinking symbol meant value. – krb686 Mar 10 '15 at 15:44
• One bit is one symbol, but one symbol isn't a bit. A symbol is a transmitted 1 or 0, a bit is one of the 8 parts of the data portion. So an 8 bit transmission is 10 symbols. It's a terminology thing. – Majenko Mar 10 '15 at 15:45
• Okay, thanks. Hopefully this is possible without delving into higher protocols and packets. – krb686 Mar 10 '15 at 15:47
• In different encoding systems a bit may be made up of multiple symbols, such as Manchester Code where a bit can be a HIGH-LOW or a LOW-HIGH symbol combination. – Majenko Mar 10 '15 at 15:47
• Ok, so instead of splitting 16 bits into 2x 8 bit values, split it into 2x 6 bit values instead. Have each half in a byte, and then set the highest bit of the first value sent. You can then know which half is which by examining the most significant bit. So the value you would send would look like 0b10xxxxxx, 0b00xxxxxx – Majenko Mar 10 '15 at 15:53