Hi dears. I am trying to use a (slightly) modified version of the UART explained in a tutorial I've found, after reading some theory about. There is one UART entity which has two components - TX and RX, which in turn, operate with 9600bps in transmition and reception of bytes. The UART has two serial ports and two "parallel" ports for doing serial<->parallel conversion. The simulation results (for RX) can be visualized here: http://puu.sh/6tnpq/db6251b4ec.png My doubt: I am writing one byte 11111111 in the parallel_tx sign and I expect it to be passed to UART_RXD (not occurring in simulation). All the right sided signals are included in the sensitive list of all process as taught me here (the original code had not). I can't see any syntax erro on the codes (I had not noted any appointment in the comments where I took it from (Toni Axe, youtube)). note: I see that the RX and TX codes are written just with one process, with IFs operating as states (not using switch as I usually do). Any help will be appreciated (I created this post after 3 days trying to do it "by my self" in my DE2). thanks. PS: I am using 20000 ps clock period.

Well, for a start, the RX.vhd has code in parrellel to the clock - this is bad practice, it should be in it's own asynchronous process. This async code contains a counter - with asynchronous counters you're just putting the code into an infinite loop - as soon as the counter increments, it will increment again over and over in 0 time, hence you will lock up the simulator. If you insist on doing a counter in an asynchronous process, you should produce a count_next signal and then register it in another process. You have an almost identical problem in tx.vhd. Inside a synchronous process, you only need to have the clock and any asynchronous resets in the sensitivity list. A sensitivity list tells the process which signals should cause a re-evaluation of the process. So for a synchronous process, the outputs can only change on a clock edge, so its not worth having other signals in there as nothing will change when they change.

Hi friends, I have just a theoretical doubt about rx uart and I would appreciate if any help. The system clock, provided for the board is 50Mhz, and I was needing a 115200bps UART. I made a mod entity that outputs 1 tick every 13 ticks from the system clock including a 16 oversampling, based on this claculations: 16 is my choice for the number of oversampling for RX bits. 115200bps is the uart baud rate. 50Mhz is the system clock. 50Mhz/(16*115200) = 27,126736111 what I assumed to be 27. So, if 50Mhz system clock has 20 ps in each cicle, after 27*20ps = 540 ps the mod entity would be generate one tick. As soon as the start bit is detected, I am interested in sampling the middle of this bit, so, at 13ª cicle or 540ps/2 = 270 ps after this start bit is being detected. All this explanation is to justify why I made the mod count from 0 to 12 to outputs one tick, for detecting the middle of start bit and after I wait two ticks of 0 to 12, I take the sample for data bits and stop bits. It gives me a conversion from 50Mhz to 1/540ps = 1.851 Hz, what I think it is close to the1.8432Hz needed to 115200bps. I attached the begin and the end of simulation. Are that correct? Thank you very much.

Hi, I have a very simple issue, could some one give me a help with that please? I made a counter from 0 to 12 to aproximate a counting from 0 to 12,5 need to make a 115200 bps rx uart. This counting should begin when the rx receives the start bit '0', and reset when the stop bit' 1' is achieved. So, the RX controls the reset of the MOD counter. I made this way to avoid the pulse going over the length of the bit for the next bytes, due to the error 0,5 in counting. the only signal I need help in the code is in rx_uart.vhd.vhd , signal en_mod_reset: std_logic:='1'; when it is '1', the mod_27_uart.vhd do not count. When it is '0', it starts to count. It works in the first byte received, but after it goes '1' forever. I know it is about semantic, but I cant see what is my falt in the code. Thanks.

according to the code you posted, en_mod_reset doesnt connect to anything...

--- Quote Start --- according to the code you posted, en_mod_reset doesnt connect to anything... --- Quote End --- Sorry I did not make it clear enough. Assume that en_mod, associated to the signal en_mod_reset in uart_rx, is connected to the reset in the mod_27. Both of them are connected to the 50MHz clock and were simulated. The circuit is working normally if I connect the reset of the mod_27 to the reset of the whole system. But i need the mod_27 reseted if no start bit in uart_rx is detected. So uart_rx controls the mod_27 reset trhough the en_mod_pin. uart_rx(en_mod) -> mod_27(reset) Thank you for your help.

UART and MODELSIM ALTERA (code attached) | Altera Community

29 Replies

Altera_Forum
Honored Contributor
11 years ago
Thank Tricky, I will try it but, as soon as I am modeling the uart through Flip-Flops,
and using two signals to do in this way, I am thinking witch is the best practice to implement it.
As a beginner Is it suggested to do it in the sequential logic process......or in the combinational part, outside the process?

sequential logic process:
entity
...
port( rx: in std_logic );
...
archtecture
...
-- two signals representing the Next State Logic register for a byte comming in port rx.
signal b_reg, b_next: std_logic_vector(7 downto 0);

-- other two signals representing the other register
signal other_b_reg, other_b_next: std_logic_vector(7 downto 0);
...
process(clk, reset)
...

-- next state logic for b and...
b_reg <= b_next;
-- ...the other register.
other_b_next <= b_reg;
other_b_reg <= other_b_next;

combinational logic:
...
process(clk,rst)
...
end process;
...
process(sensitivity list)
....
end process;
...

--outside the process.
b_reg <= b_next;
other_b_next <= b_reg;
other_b_reg <= other_b_next;

or even do i need another case statment in the finite state machine process just to pass the value from one signal to the other?

It seems that we have a hot topic here (Views: >1,218).

Thanks,

Altera_Forum

Honored Contributor

11 years ago

just register them directly:


signal rd_r : std_logic_vector(1 downto 0);
signal serial_rx_r : std_logic_vector(1 downto 0);
process(clk)
begin
  if rising_edge(clk) then
    serial_rx_r <= serial_rx_r(0) & serial_rx;
    rd_r <= rd_r(0) & rd;
  end if;
end if;

Then use rd_r(1) instead of the origional input "rd" and the same for serial_rx

Altera_Forum
Honored Contributor
11 years ago
--- Quote Start ---
just register them directly:

signal rd_r : std_logic_vector(1 downto 0); signal serial_rx_r : std_logic_vector(1 downto 0); process(clk) begin if rising_edge(clk) then serial_rx_r <= serial_rx_r(0) & serial_rx; rd_r <= rd_r(0) & rd; end if; end if;

Then use rd_r(1) instead of the origional input "rd" and the same for serial_rx
--- Quote End ---

Hi tricky, I am doing this already, for example, in the line 110 from the rx_uart.vhd:

-- left concatenate the new bit, assuming the bits are sent LSB to MSB byte_next <= rx & byte_reg(7 downto 1);

Maybe the problem is with the FIFO megafunction?

I am using the SCFIFO from altera. So, the input "rd" from this SCFIFO is connected with the output "rx_done_tick" from rx_uart.vhd.

Maybe I should use the DCFIFO, which I read that it is better for deal with metastability.

I noted too that the counter from mod_27.vhdl does not flash the leds to indicate that the counter inside is working.
The outputs in this vhdl file are in this way:

-- output logic q <= std_logic_vector(r_reg); max_tick <= '1' when r_reg=(M-1) else '0';

I think it should be corrected as you said. I'll try to double register these two outputs and test the counter first.

Then I ll increment the circuitry with uart, then with the FIFO, and see if it works.
Altera_Forum
Honored Contributor
11 years ago
--- Quote Start ---
Hi tricky, I am doing this already, for example, in the line 110 from the rx_uart.vhd:

-- left concatenate the new bit, assuming the bits are sent LSB to MSB byte_next <= rx & byte_reg(7 downto 1);

--- Quote End ---

THis assumes that the rx input is already synchronised which it isnt. You need the double register BEFORE this to ensure you get real values, not a meta stable one inside the byte(0) register.

The problem will not be the DCFIFO. THat also requires synchronised inputs.
Altera_Forum
Honored Contributor
11 years ago
--- Quote Start ---
just register them directly:

signal rd_r : std_logic_vector(1 downto 0); signal serial_rx_r : std_logic_vector(1 downto 0); process(clk) begin if rising_edge(clk) then serial_rx_r <= serial_rx_r(0) & serial_rx; rd_r <= rd_r(0) & rd; end if; end if;

Then use rd_r(1) instead of the origional input "rd" and the same for serial_rx
--- Quote End ---

I know it is a lot of questions but:

I noted that you coded inside the reset process. I am doing this "shifting register" in another process where I've implemented the FSM.

I have a process for clock and reset, and another process for FSM.

Should I implement the double register in the clock/reset process? Not in the FSM process?

This is causing to me some confusion.
Altera_Forum
Honored Contributor
11 years ago
Yes, it is. You have separated out all of your combinatorial logic into one process, and then registered it in another.

Aslong as they are placed in a clocked process that uses the correct clock, then its fine.

Altera_Forum

Honored Contributor

11 years ago

--- Quote Start ---

Yes, it is. You have separated out all of your combinatorial logic into one process, and then registered it in another.

Aslong as they are placed in a clocked process that uses the correct clock, then its fine.

--- Quote End ---

   
-- register byte_reg syncronized;
process(clk, reset)       begin
      if (reset = '1') then
         state_reg <= idle;
         baud_cnt_reg <= (others => '0');
         bits_cnt_reg <= (others => '0');
         byte_reg <= (others => '0');
      elsif (clk'event and clk='1') then
         state_reg <= state_next;
         baud_cnt_reg <= baud_cnt_next; 
         bits_cnt_reg <= bits_cnt_next; 
         byte_reg <= byte_next;
      end if;
   end process;
...
-- left concatenate the new bit, assuming the bits are sent LSB to MSB
-- other process (FSM).
 byte_next <= rx & byte_reg(7 downto 1);
...
-- out of any process, combinatorial logic.
-- Put the byte read on the output bus.
   dout <= byte_reg;

Altera_Forum
Honored Contributor
11 years ago
IT WORKED! I LOVE YOU TRICKY :D \o/
Altera_Forum
Honored Contributor
8 years ago
--- Quote Start ---
IT WORKED! I LOVE YOU TRICKY :D \o/
--- Quote End ---

hi friend, i need uart_rx , uart_tx , uart_testbench ; code for modelsim
can you send it for me as soon AS possible?
my mail: m.aghajani0000@gmail.com
thanks alot

Forum Discussion

UART and MODELSIM ALTERA (code attached)

29 Replies

Recent Discussions

USB-BlasterII mounts as "USB-Blaster variant"

Quartus Dark Theme on Linux - Solution

Error(23098) when using IPM_IOPLL on Agliex 7

Quartus 13.1 License

Highlight similar instances of a selected word fails when scrolling