Electronic – VHDL UART Realization

uartvhdl

I try to implement the following simple UART reciever. The simulations goes fine (image attached). But i encountered some problems in real hardware realiztion using Nexys 2 board.
I try to send a symbol through minicom using the following protocol
1 start bit 8 data bits 1 stop bit 115200 baud rate
Also i have 50 Mhz FPGA clock, which i directly use as UART reciever clk. UART counter count to 434 (F = 115200 Hz -> T = 8680 ns -> T = 20 ns * 434) So checking in 233 we will get the center of recieved bit.
While debugging the output of the uart i attached DATA_OUT from reciever to the Nexys board leds.

It seems to me that i get the wrong symbol codes. For example when i send '1' (00110001) i get 10011001 code
and so on

'2' 00110010 -> 10011010

'3' 00110011 -> 10011011

'4' 00110100 -> 10011000

So my suggestion is that something is wrong with the VHDL code, but i don't understand what exactly… Can anybody help me please? Thanks.

entity uart_reciever is
    Port ( clk : in  STD_LOGIC;
           rx : in  STD_LOGIC;
    recieved : out std_logic;
              en : in  STD_LOGIC;
           data_out : out  STD_LOGIC_VECTOR (7 downto 0)
              );
end uart_reciever;

architecture Behavioral of uart_reciever is
    signal count : std_logic;
    signal rec : std_logic := '0';
    signal counter : integer range 0 to 433;
begin
    process (clk)
        variable state : integer range 0 to 9 := 0;
        variable data : std_logic_vector (7 downto 0);
        variable rx_p : std_logic;
        begin
            recieved <= rec;
            if rising_edge(clk) AND en = '1' then

                if (rx_p = '1' and rx = '0') then       --  
                    count <= '1';
                    rx_p := rx;
                else 
                    rx_p := rx;
                end if;

            if (counter = 216) then
                rec <= '0';
                case (state) is
                    when 0 =>
                        if (rx = '0') then      --  -
                            state := 1;     
                   else 
                            state := 0;
                     count <= '0';
                   end if;
                    when 1 => 
                        data(0) := rx;        --  
                  state := 2;
                    when 2 => 
                        data(1) := rx;
                  state := 3;
                    when 3 => 
                        data(2) := rx;
                  state := 4;
                    when 4 => 
                        data(3) := rx;
                  state := 5;
                    when 5 => 
                        data(4) := rx;
                  state := 6;
                    when 6 => 
                        data(5) := rx;
                  state := 7;
                    when 7 => 
                        data(6) := rx;
                  state := 8;
                    when 8 => 
                        data(7) := rx;
                  state := 9;
                    when 9 => 
                        state := 0;
                  count <= '0';
                        if (rx = '1') then
                            data_out <= data; 
                            rec <= '1';
                        end if;
                end case;
            end if;
        end if;
    end process;

    process (clk)
    begin
        if rising_edge(clk) then       
        if (count = '1') AND (counter < 434) then
                counter <= counter + 1; 
        else 
                counter <= 0;
        end if;
        end if;
end process;

enter image description here

Best Answer

Your implementation looks basically sound. Your 2nd process essentially counts off whole-bit times; then your 1st process detects the leading edge of the start bit, synchronizes the whole-bit counter to that edge, and you then sample the data every time the phase point of the whole-bit counter indicates the middle of the bit has arrived. Implementations vary, but the algorithm is classic - get to the center of the start bit, then sample at regular bit times thereafter.

Your error examples are interesting though. Bearing in mind that the LSB comes first, it looks like your system usually gets the first two, often three bits correct. And in every example, the MSB is incorrectly '1', which suggests the possibility that that '1' is in fact the stop bit.

All in all, it looks quite like a rate problem, specifically, like the sampling rate is just a bit too low compared to the actual data rate. I think I'd try 01000000 for a test vector; if a slow sampling rate is the problem, you're apt to read it as 00100000. Just for laughs you could try dialing down the whole-bit counter range from 434 to say 430 or 425 and see what happens.

And lastly, in the 'have you tried unplugging it and plugging it back in' department, (1) no doubt you've already verified that the oscillator in the real system is in fact the same 50MHz you simulated at, and not something like 48MHz, and (2) you've fed the test signal to some other piece of equipment known to function correctly at 115.2, and vetted that the signal source isn't running fast.

Related Solutions

Electronic – VHDL: receive module randomly fails when counting bits

I don't see a synchronizer on the rx data line.

All asynchronous inputs must be synchronized to the sampling clock. There are a couple of reasons for this: metastability and routing. These are different problems but are inter-related.

It takes time for signals to propagate through the FPGA fabric. The clock network inside the FPGA is designed to compensate for these "travel" delays so that all flip flops within the FPGA see the clock at the exact same moment. The normal routing network does not have this, and instead relies on the rule that all signals must be stable for a little bit of time before the clock changes and remain stable for a little bit of time after the clock changes. These little bits of time are known as the setup and hold times for a given flip flop. The place and route component of the toolchain has a very good understanding of the routing delays for the specific device and makes a basic assumption that a signal does not violate the setup and hold times of the flip flops in the FPGA. With that assumption and knowledge (and a timing constraints file) it can properly place the logic within the FPGA and ensure that all the logic that looks at a given signal sees the same value at every clock tick.

When you have signals that are not synchronized to the sampling clock you can end up in the situation where one flip flop sees the "old" value of a signal since the new value has not had time to propagate over. Now you're in the undesirable situation where logic looking at the same signal sees two different values. This can cause wrong operation, crashed state machines and all kinds of hard to diagnose havoc.

The other reason why you must synchronize all your input signals is something called metastability. There are volumes written on this subject but in a nutshell, digital logic circuitry is at its most basic level an analog circuit. When your clock line rises the state of the input line is captured and if that input is not a stable high or low level at that time, an unknown "in-between" value can be captured by the sampling flip flop.

As you know, FPGAs are digital beasts and do not react well to a signal that is neither high nor low. Worse, if that indeterminate value makes its way past the sampling flip flop and into the FPGA it can cause all kinds of weirdness as larger portions of the logic now see an indeterminate value and try to make sense of it.

The solution is to synchronize the signal. At its most basic level this means you use a chain of flip flops to capture the input. Any metastable level that might have been captured by the first flip flop and managed to make it out gets another chance to be resolved before it hits your complex logic. Two flip flops are usually more than sufficient to synchronize inputs.

A basic synchronizer looks like this:

entity sync_2ff is
port (
    async_in : in std_logic;
    clk : in std_logic;
    rst : in std_logic;
    sync_out : out std_logic
);
end;

architecture a of sync_2ff is
begin

signal ff1, ff2: std_logic;

-- It's nice to let the synthesizer know what you're doing. Altera's way of doing it as follows:
ATTRIBUTE altera_attribute : string;
ATTRIBUTE altera_attribute OF ff1 : signal is "-name SYNCHRONIZER_IDENTIFICATION ""FORCED IF ASYNCHRONOUS""";
ATTRIBUTE altera_attribute OF a : architecture is "-name SDC_STATEMENT ""set_false_path -to *|sync_2ff:*|ff1 """;

-- also set the 'preserve' attribute to ff1 and ff2 so the synthesis tool doesn't optimize them away
ATTRIBUTE preserve: boolean;
ATTRIBUTE preserve OF ff1: signal IS true;
ATTRIBUTE preserve OF ff2: signal IS true;

synchronizer: process(clk, rst)
begin
if rst = '1' then
    ff1 <= '0';
    ff2 <= '0';
else if rising_edge(clk) then
    ff1 <= async_in;
    ff2 <= ff1;
    sync_out <= ff2;
end if;
end process synchronizer;
end sync_2ff;

Connect the physical pin for the N64 controller's rx data line to the async_in input of the synchronizer, and connect the sync_out signal to your UART's rxd input.

Unsynchronized signals can cause weird issues. Make sure any input connected to an FPGA element that isn't synchronized to the clock of the process reading the signal is synchronized. This includes pushbuttons, UART 'rx' and 'cts' signals... anything that is not synchronized to the clock that the FPGA is using to sample the signal.

(An aside: I wrote the page at www.mixdown.ca/n64dev many years ago. I just realized that I broke the link when I last updated the site and will fix it in the morning when I'm back at a computer. I had no idea so many people used that page!)

Electronic – Why is the simple counter VHDL not working? Where did the signals go

the rising_edge() parameter is only really for clock signals. One option would be the following:

clk_proc: process( clk, switch1, switch0 )
begin
    if switch1 = '1' then
        counter <= ( others => '0' );
    elseif rising_edge( clk ) then
        if switch0 = '1' then
            counter <= counter + 1;
        end if;
    end if;
end process;

This is known as an asynchronously reset process, which means that it'll reset the counter whenever reset (switch1) is high, regardless of clock state. A synchronously reset process would look the same as your second example:

clk_proc: process( clk, switch1, switch0 )
begin
    if rising_edge( clk ) then
        if switch1 = '1' then
            counter <= ( others => '0' );
        elsif switch0 = '1' then
            counter <= counter + 1;
        end if;
    end if;
end process;

You did state though that your second example didn't work as expected. My suspicion is that this is because the signals driving it are switches rather than clocked logic signals. Switches don't actually switch instantaneously, instead bouncing between on and off a few times before settling. You need to implement some sort of debounce process to produce a signal which is synchronous with your clock and can control your timer.

It's also worth mentioning that FPGA design is a lot easier if you simulate stuff first. Xilinx ISE includes a simulator - create a testbench and use it! That lets you easily see what's happening in your implementation before you ever get near hardware.

Best Answer

Related Solutions

Electronic – VHDL: receive module randomly fails when counting bits

Electronic – Why is the simple counter VHDL not working? Where did the signals go

Related Topic