Re: Converting Aynchronous UART to Synchronous USART

Altera_Forum · ‎11-20-2015

OpenCores has a very stable uart (attached) that integrates easily to altera/qsys.

My goal is to tweak it just enough so that it transmits on the rising edge and receives on the falling edge of a separate dedicated 1mhz clock.

Looking at the tx state machine, it looks to run off the system clock, but gets enabled via a 16x baud clock:


module uart_transmitter (wb_clk, wb_rst_i, baud_16x_enable...
always @(posedge wb_clk or posedge wb_rst_i)
begin
  if (baud_16x_enable)
  begin
    case (tstate)
    s_idle     :    if (~|tf_count) // if tf_count==0
  ...
Where the baud_16x_enable is generated from a divided system clock:
// Enable signal generation logic
always @(posedge wb_clk or posedge wb_rst_i)
begin
    if (wb_rst_i)
        baud_16x_enable <=# 1 1'b0;
    else
        if (|dl & ~(|dlc))     // dl>0 & dlc==0
            baud_16x_enable <=# 1 1'b1;
        else
            baud_16x_enable <=# 1 1'b0;
end

I was thinking to make it synchronous all I'd have to do is keep it enabled (baud_16x_enable <= 1'b1), and replace the wb_clk driving the transmitter, by my sync_clk in order for the state machine to clock out synchrounsly from the dedicated clock. Would it be this easy, or would this not work?

Altera_Forum · ‎11-20-2015

You can certainly separate the TX & RX paths such that they run from separate clocks. You can also play with the TX timing such that it 'transmits on the rising edge'.

However, I'm not sure about your RX idea - I'm not sure you're explaining it fully. 'receives on the falling edge' - how are you going to ensure your RX data lines up nicely with your falling edge? By all means run your logic from the negative edge of a clock (although that doesn't achieve anything) but you'll still have to detect an edge such that you can sample the RX data at an appropriate point.

If you simply modify 'baud_16x_enable' to 'keep it enabled' your logic will run 16 times faster than it should.

Try your change, simulate it and see if it behaves as you want.

Cheers,

Alex

Altera_Forum · ‎11-23-2015

--- Quote Start ---

You can certainly separate the TX & RX paths such that they run from separate clocks. You can also play with the TX timing such that it 'transmits on the rising edge'.

However, I'm not sure about your RX idea - I'm not sure you're explaining it fully. 'receives on the falling edge' - how are you going to ensure your RX data lines up nicely with your falling edge? By all means run your logic from the negative edge of a clock (although that doesn't achieve anything) but you'll still have to detect an edge such that you can sample the RX data at an appropriate point.

If you simply modify 'baud_16x_enable' to 'keep it enabled' your logic will run 16 times faster than it should.

Try your change, simulate it and see if it behaves as you want.

Cheers,

Alex

--- Quote End ---

I was describing just the approach for the Tx portion as the first step. Incidentally, the state machine had to be slightly tweaked since it was counting 16 clocks before transitioning states, so had to change that as well, but it's working fine.

For the Rx portion, it also looks like its counting 8 clocks before reading the data line, so a similar tweak might work, i.e. no clock counting, just latching the data based on a sync clock instead of the system wishbone clock.

Altera_Forum · ‎11-25-2015

Yes, you can latch the Rx data on a 'sync clock'. However, isn't that over complicating it? I'm assuming you'll then have to transfer the recovered data onto the 'system wishbone clock' domain. Why not just use that clock - as the original design (almost certainly) does? And how are you intending to generate the 'sync clock'?

Cheers,

Alex