problem facing implementing a RS232 transmitter in VHDL for Spartan 3E starter board

[basab]

Hi I am facing a unusual problem when implementing a RS232 transmitter problem. I have written a VHDL script which includes a UART component form Digilent. Problem is that logically my program should send the letter 'A' then 'B' then 'C' and then 'D' and the process should repeat. But upon programming the Chip with bit file, the program transmit only 'B' and 'D' and repeat the same in Hyperterminal. I am not getting why its not transmitting what is expected i.e. A B C D repeatedly. Please guide me where I am going wrong.

in the process code below:

sys_clk is the clock signal
reset is always 0 for my case
CLKp is signal which remains high for total time while transmitting ABCD and goes low once RST is made zero 0.

---

Code C - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
tx_output: process (sys_clk,reset,CLKp) is
variable opbits1: std_logic_vector(7 downto 0);
variable opbits2: std_logic_vector(7 downto 0);
variable opbits3: std_logic_vector(7 downto 0);
variable opbits4: std_logic_vector(7 downto 0);
  begin
  
      if CLKp='1' then
                     opbits1:= outputbits(7 downto 0);
              opbits2:= outputbits(15 downto 8);
              opbits3:= outputbits(23 downto 16);
              opbits4:= outputbits(31 downto 24);
                      
                 if rising_edge(sys_clk) then
                    if uart_tx_ready ='1' then
                                            
                        if lsb=0 then 
                            uart_tx_data <= opbits1; ---- should print A
                            uart_tx_enable <='1';
                            lsb<=lsb+1;
                        elsif lsb=1 then 
                            uart_tx_data <= opbits2; ---- should print B
                            uart_tx_enable <='1';
                                lsb <=lsb+1;
                        elsif lsb=2 then
                            uart_tx_data <= opbits3; ---- should print C
                                uart_tx_enable <='1';
                            lsb <=lsb+1;
                        elsif lsb=3 then
                            uart_tx_data <= opbits4; ---- should print D
                                uart_tx_enable <='1';
                            RST <='1';
                             lsb <=0;
                        end if;
                else
                     uart_tx_enable <='0';
                end if;
            end if;  
         else
             RST <='0';      
       end if;                      
end process;

---

 

[std_match]

It probably takes some time from "uart_tx_enable <= '1' " to "uart tx_ready = '0' ". You should not change "uart_tx_data" during that time.

Edit:
You should do a simulation.

 

[TrickyDicky]

what is clkp, and why are you using it as an asynchronous load/enable? not really good practice.

do you have a testbench? have you simulated your design?

 

[FvM]

Even if you don't review the UART component code, you can guess how it works:

If you set uart_tx_enable in one clock cycle, uart_tx_ready will be reset synchronously in the next clock cycle. Combining this operation with your code, you'll see why the state machine is skipping one state.

A possible simple solution

if (uart_tx_ready ='1') AND (uart_tx_enable ='0') then

 

[basab]

Hi All thanks for your suggestions!!! The problem not sorted yet. @FVM , I applied your suggestion but it stop printing this time in Hyperteminal window. One more observation is that if I alter opbits3 and opbits4, system again stop printing this time in Hyperteminal. Otherwise it prints BD. I am attaching my complete project folder for your kind check. It will be very helpful for me. As I am using 9600 baud rate and clock frequency of 50MHz. One cycle goes to around miliseconds so simulation might be not possible in ISE ( i am very new in this field). If possible please suggest.
Thanks in advance
Basab

 

[ads-ee]

You should have run a simulation.

I had a feeling the problem wasn't exactly what others thought it might be. I had a feeling it was a more rudimentary problem with designing hardware vs software.

So I ran a quick simulation on your file and discovered this after running it for a < 1ms.

as you can see you your CLKp "enable" is allowing the logic to pass through multiple output states as it keeps enabling everything, every clock cycle (50 MHz). CLKp should be just a single clock wide pulse if it's truly an enable.