Simple Verilog RS232 Receiver - ETO Exclusive

[BrownOut]

There have been a few questions about this lately. The following code receives a character over an RS-232 connection. It's been tested and verified using Xilinx PFGA. For those who have this as an assignment, no cheating and just copying my code! But I'll be happy to discuss it and how/why it works. Use the following settings in your terminal program:

Baud : 9600
Data Bits : 8
Parity : None
Stop Bits : 1
Flow Control : None

Code:

module loopback
(clock,
 reset,
 RS232_DCE_RXD,
 RS232_DCE_TXD,
 receive_data);

input clock;
input reset;
input RS232_DCE_RXD;
output RS232_DCE_TXD;
output [7:0] receive_data;

parameter rcv_bit_per = 5208; //102.4uS
parameter half_rcv_bit_per = 2604; //51.2uS
//--State Definitions--
parameter ready = 2'b00;
parameter start_bit = 2'b01;
parameter data_bits = 2'b10;
parameter stop_bit = 2'b11;

reg [12:0] counter, n_counter;  //9765.625Hz
reg [3:0] data_bit_count, n_data_bit_count;
reg [7:0] rcv_sr, n_rcv_sr;
reg [1:0] state, n_state;

assign RS232_DCE_TXD = RS232_DCE_RXD;
assign receive_data = rcv_sr;

always @(state, RS232_DCE_RXD, counter, data_bit_count) begin
  n_rcv_sr <= rcv_sr;
  n_counter <= counter;
  n_state <= state;
  n_data_bit_count <= data_bit_count;

  case (state)

    ready: begin
      if(RS232_DCE_RXD == 0) begin
	  n_state <= start_bit;
	  n_counter <= counter + 1;
	end
      else begin
        n_state <= ready;
	  n_counter <= 0;
	  n_data_bit_count <= 0;
	end
    end

    start_bit: begin
	
	if(counter == half_rcv_bit_per) begin
	  n_state <= data_bits;
	  n_data_bit_count <= data_bit_count + 1;
	  n_counter <= 0;
	end
	else begin
	  n_state <= start_bit;
	  n_counter <= counter + 1;
	end
    end

    data_bits: begin
	if(counter == rcv_bit_per) begin
    //n_rcv_sr <= {rcv_sr[6:0], RS232_DCE_RXD};
	 n_rcv_sr <= {RS232_DCE_RXD,rcv_sr[7:1]};
    n_data_bit_count <= data_bit_count + 1;
	  n_counter <= 0;
	  if(data_bit_count == 8)
	    n_state <= stop_bit;
	end
	else
	  n_counter <= counter + 1;
    end

    stop_bit: begin
	n_counter <= counter + 1;
	if(counter == rcv_bit_per) //should be 1/2 stop_bit period
	  n_state <= ready;
	end
endcase
end //always

//clock proc
always @(posedge clock or posedge reset) begin
  if(reset == 1) begin
    state <= ready; 
    rcv_sr <= 0;
    counter <= 0;
    data_bit_count <= 0;
  end
  else begin
    state <= n_state;
    rcv_sr <= n_rcv_sr;
    counter <= n_counter;
    data_bit_count <= n_data_bit_count;
  end
end


endmodule

 

[Ubergeek63]

It is impossible for verilog to represent RS232... what you have there is a rudimentary UART (Universal Asynchronous Receiver/Transmitter), though technically it is not even that since it is not programmable.

RS232 it really a hardware interface complete with the definition of cable impedance, I/O impedance, max cable lengths, and +/-6V to +/-15V signaling voltage. You can use a USART at digital voltages, but that is NOT RS232, only a synchronous interface.

 

[BrownOut]

HA! Well, I know what I have, but thanks for trying to educate me. Actually, I made no such claim that RS232 could be represented in verilog. I refer you to the title, "Simple Verilog RS232 Receiver" Simple because it is a rudimentary design, RS232 because it implements a subset of the standard bit stream protocol, Receiver because it only receives the bitstream and assembles the character being sent. I would be amazed if anyone thinks I'm trying to represent the entire RS232 standard with my simple design. The purpose is to show the few members who are trying to implement a basic comm system for their FPGA development that communicates via a computer RS232 (or in my case, communicates through the USB to RS232 converter) I set up the baud rate and other parameters to be the same as my drivers default values, but it would be relative simple to make these parameters programmable, and this simple reference design can be serve as a starting point to a full-throated UART. I think those who are interested in developing and learning serial communications could get a good "kickstart" from trying out this design, because it's a very simple entry point, and can use it with commodity hardware and software, though serial ports are getting scarce. That’s unfortunate for those getting into serial comm., IMO.

 

[Ubergeek63]

the same thing applies: RS232 refers to the voltages and wire types. Verilog is strictly logic, there is no such thing as 15V in Verilog. What you have is an async receiver... it becomes RS232 when you hang an RS232 receiver IC out there.

That said I agree that it is a shame you cant find RS232 ports anymore ... **broken link removed**

 

[BrownOut]

RS232 is more than just a voltage specification. But anyway, this module allows communication with all computer's RS232 serial port. This is the protocal used by nearly all RS232 ports. But you can call it whatever you want. It works, that's the point.

 

[Ubergeek63]

No it is NOT the point!

The point is that it is NOT RS232 UNTIL it is +5 to 15V mark and -5 to 15V space! (or the other way around, I forget which polarity it is off hand)

Also M$ WinBlows default settings do not qualify as "nearly all", nearly all programs actually run much faster these days. It is ridiculous to think that 56K analog modems, being the most likely current product to be hung on a serial port, would be run at 9.6K. Even back when they were commonly put on RS232 ports they were put at 115.2K ... even dot matrix printers would be run faster than 12 lines a second (9600/10/80 characters per line)!

What you have is a rudimentary shift register with a little logic hanging off of it. ever hear of https://opencores.org/projects? there are at least 7 actual UARTs there including https://opencores.org/project,uart16550 the industry standard and what we all had to go out and buy if we wanted anything resembling a good data rate when HS modems (14.4K + compression) came on the market!

 

[mneary]

Your Xilinx FPGA will blow up if you connect it to an RS232 line.

You need, at a minimum, a voltage translator such as MAX232 (old but still useful). Since translator chips are inverting, you also need to pay attention to that (Logic '1" is -5 to -15V, logic '0' is +5 to +15V.)

 

[nigelwright7557]

I could do it in much less code in a PIC bit banged !

 

[killivolt]

Your Xilinx FPGA will blow up if you connect it to an RS232 line.

You need, at a minimum, a voltage translator such as MAX232 (old but still useful). Since translator chips are inverting, you also need to pay attention to that (Logic '1" is -5 to -15V, logic '0' is +5 to +15V.)

The conversation around this is interesting, we used this exact setup. Using a MAX232 chip too!

Worked pretty good. The engineers had some trouble working it out, but it proved itself in the end.

 

[Ubergeek63]

Your Xilinx FPGA will blow up if you connect it to an RS232 line.

You need, at a minimum, a voltage translator such as MAX232 (old but still useful). Since translator chips are inverting, you also need to pay attention to that (Logic '1" is -5 to -15V, logic '0' is +5 to +15V.)

That is essentially my point though depending on which chip it might not blow... if the substrate diodes can handle it the chip could survive ... of course that is assuming you are on a test bench and not a long staticy line - that is where it is nice to use one of the newish 15KV RS232 chips!

 

[BrownOut]

No it is NOT the point!

The point is that it is NOT RS232 UNTIL it is +5 to 15V mark and -5 to 15V space! (or the other way around, I forget which polarity it is off hand)

Also M$ WinBlows default settings do not qualify as "nearly all", nearly all programs actually run much faster these days. It is ridiculous to think that 56K analog modems, being the most likely current product to be hung on a serial port, would be run at 9.6K. Even back when they were commonly put on RS232 ports they were put at 115.2K ... even dot matrix printers would be run faster than 12 lines a second (9600/10/80 characters per line)!

What you have is a rudimentary shift register with a little logic hanging off of it. ever hear of Projects :: OpenCores? there are at least 7 actual UARTs there including UART 16550 core :: Overview :: OpenCores the industry standard and what we all had to go out and buy if we wanted anything resembling a good data rate when HS modems (14.4K + compression) came on the market!

It IS the point. First of all, it doesn't matter if ports run faster these days, as long as the bit rate is programmable. But even that doesn't matter, because the rate on my module is easily changed by just changing a few parameters. So, it can run at any rate, including the modern faster rate. And it does communicate with the RS232 port on my computer, and most others as well. And as long as the discussion has gotten all anal, it's perfectly possible for verilog to describe an end-to-end RS232 system because verilog has no knowledge, nor does it care, about voltage levels. It doesn’t care if the levels are =/-5-15V, TTL, CMOS or whatever. It doesn’t specify any voltage levels, rather leaves that up to the implementation tools. So, it is totally possible and appropriate to describe a total RS 232 system using verilog. I should know, as I've been doing this for about 9 years now.

The purpose of my post was to show some of our members a very simple receiver for connecting to the RS232 comm port on their computers, because there have been some questions about. I know what I've created, and I really, really don't need anyone to tell me what it is. I've connected my FPGA board to the port on my computer and have established communications. It's really not all that hard to understand.

And FYI, I've heard of opencores and am a member. What relevace is that? What I'm showing is the most rudimentary module that will communicate. That's it and that's all. I'm not trying to recreate a UART and I think I've made that more than clear. So there is no need to go on and on and on and on and on and on about UARTS anymore. If I wanted to use a UART, I would have used one. But I didn't want to , so I created a very quick and simple module to do a small PART of what a UART would normally do. It's not really all that unusual to do something like that when you don't need full-blown UART functionality.

 

[BrownOut]

Your Xilinx FPGA will blow up if you connect it to an RS232 line.

You need, at a minimum, a voltage translator such as MAX232 (old but still useful). Since translator chips are inverting, you also need to pay attention to that (Logic '1" is -5 to -15V, logic '0' is +5 to +15V.)

My development board includes an onboard translation chip, as most board with serial ports do. The output of the chip is already correct logic for mark/space.

 

[Ubergeek63]

you just dont get it do you brownout?

the point is that no matter what you do in your FPGA it is NOT RS232, connecting your FPGA DIRECTLY to your PC would likely BLOW IT OUT! furthermore, unless your code actually implements framing and say five samples per bit, it is NOT a reliable interface but still only a shift register with a little logic hanging off of it. that, while fine for a synchronous interface, tends to be unreliable for an asynchronous one.

our point was that it is NOT an RS232 receiver, it is ONLY RS232 AFTER your boards RS232 chip, no matter how ill informed you are.

 

[BrownOut]

No you don't get it. It's been tested and has never failed to capture the correct data. It implements a receiver for RS232 data, and is currently connected to the computer's RS232 port and receiving data. It's not a synchronous interface, but an asynchronous one. And my FPGA doesn't blow up for reasons I've already described.

Call it whatever you want, I really don't care about your terminology. The code implements an interface to receive RS232 data from a computer RS232 port. It has been tested and works. Go ahead of throw all the fits you want, but success is undeniable.

 

[Ubergeek63]

No you don't get it. It's been tested and has never failed to capture the correct data. It implements a receiver for RS232 data, and is currently connected to the computer's RS232 port and receiving data. It's not a synchronous interface, but an asynchronous one. And my FPGA doesn't blow up for reasons I've already described.

Call it whatever you want, I really don't care about your terminology. The code implements an interface to receive RS232 data from a computer RS232 port. It has been tested and works. Go ahead of throw all the fits you want, but success is undeniable.

For the reasons described, ie you HAVE an RS232 chip, it does not blow up.

In the situation you describe, what is it a 3' wire in your office?, any fool can make a MARGINAL system work "reliably".

According to the STANDARD, you should be able to run in a NOISY industrial environment on a ONE THOUSAND FOOT link. I'd wager it won't! The REAL UARTs take multiple samples to make sure they are getting the right state when noise is causing it to be other than what the sender drove the line with.

Yours, on the other hand, WILL receive bad bytes in those situations with no way of tracking down as to why since it would be caused by an occasional noise spike that, even when it is there, needs to coincide with a bit of the proper polarity that it can "switch" it at the very instant that you are sampling it.

BTW it is normally advantageous to listen and learn from those who are more experienced and knowledgeable than yourself, no matter how it effects your pride.

 

[BrownOut]

It would certainly be advantageous for you to listen and learn then. Any fool can take random shots and make up phony issues over someone else's designs. I'd wager it works in noise environments and over the same length as a real UART. In fact, I know it will. How do I know this? Well for one thing, the standard requires the signal to be stable over the sample period, no matter what other interferences are in the area. But just as important, I cracked the code on real UARTS, and guess what I found at the heart of the receive module? Essentially, it's exactly what I produced. The only difference is the real UART has additional states for error detection/parity bits. So, in effect, I've recreated the receive channel of a real UART, and you've gone and made up some other, unnecessary and extraneous requirements that would not make the receiver any more reliable than it already is.

I've created a simple receiver that works perfectly and for some reason, you just can't stand it. Tsk, tsk... I hope those looking for a starting place to develop their own FPGA code can see past all of your distortions and understand they can use this code to get started, as it's essentially the same as in real UARTS.

And if you want people to listen to you, try being less arrogant.

 

[mneary]

I see (post #12) that you have a translation chip between the UART in Xilinx and RS232.

 

[Mikebits]

I really don't get why people are busting your chops Brown, It seems that your nice gesture of offering HDL code has only rewarded you with a slap in the face. It looks to me that your UART in conjunction with a RS-232 interface chip makes a complete serial comm device. Isn't error correction and all that goo handled in software? Well, I think it is nice that you chose to share your code.

 

[BrownOut]

Thanks Mikebits. All I can say about that is I see people doing that from time to time here, with no apparent purpose. I hope someone can benefit from this and cut through all the BS. mneary: there are at least 3 of us on here using FPGA developemnt boards, complete with translation chips. I should have made that more clear from the start, but in the back of my mind, I was writing to those who already have it.

 

[Ubergeek63]

It would certainly be advantageous for you to listen and learn then. Any fool can take random shots and make up phony issues over someone else's designs. I'd wager it works in noise environments and over the same length as a real UART. In fact, I know it will. How do I know this? Well for one thing, the standard requires the signal to be stable over the sample period, no matter what other interferences are in the area. But just as important, I cracked the code on real UARTS, and guess what I found at the heart of the receive module? Essentially, it's exactly what I produced. The only difference is the real UART has additional states for error detection/parity bits. So, in effect, I've recreated the receive channel of a real UART, and you've gone and made up some other, unnecessary and extraneous requirements that would not make the receiver any more reliable than it already is.

I've created a simple receiver that works perfectly and for some reason, you just can't stand it. Tsk, tsk... I hope those looking for a starting place to develop their own FPGA code can see past all of your distortions and understand they can use this code to get started, as it's essentially the same as in real UARTS.

And if you want people to listen to you, try being less arrogant.

they are not an "unnecessary and extraneous requirements", they are real world realities. I am a DESIGN ENGINEER that deals with this **** every day. What you can get working reliably in mommy's basement is NOT what the STANDARD specifies. I do not deny that you got it working sufficient for your needs, I deny that it is to spec and that it will NOT work where a REAL one would.

I never said that your shift register did not demonstrate rudimentary functionality, I said that it is not up to professional application in and RS232 interface in the environment that RS232 is MEANT to be capable of functioning in!