[PC FPGA interface via RS-232 ]how to fit data to my component ?

Hello Hachani,

You need to develop a serial protocol suitable for your application.

If all your messages to the FPGA take the form of an address and a register to modify you could consider:

word 1     address

word 2     data

word 3     checksum

and separate the messages by an intermessage timeout.

This can be  quite reliable:

if the time since the last word was received exceeds some limit (typically 10-100mS) the receiving state machine resets. As each of the three words is received it is put into a buffer, when all three are received the FPGA checks the checksum against the other two words and copies the data to the right place if it's good. Finally the state machine resets and waits for the next message.

Of course you can expand this protocol for multibyte addresses or data or both.

Michael Kellett

Hello Michel

Thanks for your answer , it's very good idea to define my own protocol , my longest control data has a size of 32byte , so my protocol will be a frame of 33 bytes : 1 byte (address) + 32 byte data , still i have some questions:

Since the communication is wired (length wire about 30cm maximum ), do yo think i can do this protocol without checksum ?

also another question , i'm receiving data from the UART in 8 bit each time , so do you think the best solution for my protocol is to count 33 bytes and then fit data the correspondent component ?

thanks.

Ahmed Hachani

Hello Hachani,

You can almost certainly do without a checksum from a data transmission point of view but it makes it hard for a very simple protocol to be sure that it has the complete message and nothing else.

It may be a problem for you to buffer a complete 34 byte message in the FPGA so as an alternative you could consider sending 32 separate three byte messages (nice and simple if speed is not the primary concern).

Another (more complicated) approach is to use two extra connections from FPGA to processor for handshake (perhaps not too easy from Labview on a PC).

If you are using the inter message gap time to separate messages I think you should have a checksum - otherwise a delay in sending  a byte of data by the PC will confuse the FPGA into thinking it has a new message start.

It makes for  a much more robust system if the FPGA acknowledges receipt of messages by sending back some data to indicate if the message was received and acted upon.

Michael Kellett

Hello Michel;

thanks for your detailed answer, still i need more clarification

You can almost certainly do without a checksum from a data transmission point of view but it makes it hard for a very simple protocol to be sure that it has the complete message and nothing else.

   withou checksum, i can do some hardware testing in this case, for example , if i will send data to a DAC i will just check the analog level with an oscilloscope, is it sufficient like this ?

 

It may be a problem for you to buffer a complete 34 byte message in the FPGA

 

i don't see really where is the problem ! do you mean that the problem in buffering 34 byte consume lot of spce into the FPGA ?

as an alternative you could consider sending 32 separate three byte messages (nice and simple if speed is not the primary concern).

the idea now is to write a finite state machine detect the first byte sent , and then (if i want to do serially as you suggest) i will  demultplexe the dat that came just after address byte, but even in this case i need to buffer the hole frame !!

If you are using the inter message gap time to separate messages I think you should have a checksum - otherwise a delay in sending  a byte of data by the PC will confuse the FPGA into thinking it has a new message start.

for the UART IP there's a signal (RXRDY) that indicate when we have  a new data (8 bit), for the  FPGA confusing part , between tow message (i mean by message a frame of 32 byte)this why i thought about making a counter that count 32 byte (by monitoring the RXDY signal )and buffering them, by this method i'm sure that there is no confusion between message

Thanks

Ahmed Hachani

Hello Hachani,

I'm assuming that you are doing this work because either you want to learn good practice or because you need to make a device that works. In either case you should try to design a robust communication between the PC and LabView and your FPGA. (I'm guessing that the LabView is running on a PC.)

In any multiple word serial communication protocol there is an issue with framing (a data frame is a group of words) - how does the receiver know that it has exactly one frame of data. It is essential that it should know because the meaning of the data words is dependent on their position in the frame. It is highly desireable that the transmitter should know when messages have been correctly received.

You can use hardware handshake lines or timing or a combination of the two to define frames. I shan't prove it here but you need at least three handshake lines to fully define and control the transmission and reception of frames without using timing. These control lines are not generally available/controllable in a useful way from a PC serial port so it's easier to use a timing defined frame.

We specify a maximum inter-word time (Tw) so we know that if Tw seconds have passed since a word was received then the next word will be the start of  a new frame. If we can identify the end of a frame from its content or length we may know that the next word is the start of  a frame without waiting for Tw.

Now all you LabView must do is send messages where the inter-word time is less than Tw. If you don't check that the FPGA received the message you must wait at least Tw before sending another frame - this can be rather slow.

If the frame contains  a checksum the receiver has a way of detecting errors - this is not essential but will very often be useful. If the data link is not 100% reliable the checksum will help in operation but it is also very useful in development because it tends to make bugs much more visible.

The amount of data in each message depends on the application - if you can support a buffer of 34 bytes it may make sense to use one message for all the data.

In order to debug your device reliably you should provide a means of reading data out of the FPGA - checking data with a scope is OK for a quick look but can't be automated and will not easily spot a 1 bit error in an 8 bit word.

If I were designing your interface I would use messages containing 3 words, command, data, checksum and the FPGA would reply with 3 words command, data, checksum.

The LabView would issue commands and for every command it would get a reply.

You would need commands for:

set address

write data

read data

The reply echos the command so that the controller knows if it is the reply to the command it expected. It is a good idea to set one bit in the command echo that is never set by a command so that the two can't be mixed up.

It would be reasonable to arrange that write and read data operations incremented the address pointer so that you would need to send only one address command to read all the data.

The advantages of this protocol are that it is simple, uses few FPGA resources, is self checking, is testable and is expandable.

Have fun !

Michael Kellett

I would consider using the PicoBlaze (FREE Xilinx 8bit soft core) that is only 96 slices. This you could use to process your incomming data stream and then though its I/O ports pass the data out to other sub units.

@Paul,

PicoBlaze is only available on Xilinx FPGAs. Hachani still has exactly the same issues re. serial protocol if he uses an embedded soft processor or RTL level coding using VHDL, Verilog or whatever.

But since you mention it  - how good are the debugging/development tools for PicoBlaze - can you co-simulate PicoBlaze code with VHDL fabric or does it all have to be done at RTL level ?

Michael Kellett

Depends on chip as compiler can be a issue with older ones. However there are great little tools like OpenPICIDE that you can simulate code before generating the .v or .vhdl prom image. This is normally enough to get it working in the fabric. Well the code I've written, if it simulates, it runs.

I've seen, but not used C complies for the PicoBlaze but not convinced they would really help as its such a tiny device ASM is easy to use on it.

True simulation debugging would have to be at RTL - PicoBlaze wraps up into a single component so can be looked at as a black box.

I've read that people that changed the entity to bring out things like PC and other internals.

You get what you pay for.

Was just thinking it may be a good option as a FSM is going to get big quickly and is working with what is really a very slow interface (Serial) and a soft core would be better.

Depends on chip as compiler can be a issue with older ones. However there are great little tools like OpenPICIDE that you can simulate code before generating the .v or .vhdl prom image. This is normally enough to get it working in the fabric. Well the code I've written, if it simulates, it runs.

I've seen, but not used C complies for the PicoBlaze but not convinced they would really help as its such a tiny device ASM is easy to use on it.

True simulation debugging would have to be at RTL - PicoBlaze wraps up into a single component so can be looked at as a black box.

I've read that people that changed the entity to bring out things like PC and other internals.

You get what you pay for.

Was just thinking it may be a good option as a FSM is going to get big quickly and is working with what is really a very slow interface (Serial) and a soft core would be better.