How to design UART peripherals IP?

[antercreeper]

(I have read some method of oversampling, but well, I hate this methodology......)(I am very unhappy about these async things(mismatching over baud rates, clock jitter, etc...) )...... I would rather does with I2C or SPI.
So how to achieve clock synchronizing over UART?(like the serdes's clock data recovery?)
maybe need some analog things (achieve some phase moving?) instead of RTL? (means that you need to pay some $ while making ASICs instead of working over FPGAs)

[mtwieg]

UART is fundamentally asynchronous. Adding clock recovery wouldn't make it a better UART, but something else entirely, and I would not expect it to work any better with "standard" UART devices. If both sides are FPGAs which you have control over, then by all means do something fancy like adding NRZ or 8b/10b encoding. But if both sides were FPGAs then I doubt you would be stuck with UART to begin with.

Besides, UART is generally as reliable synchronous interfaces like I2C/SPI so long as the baud rates of the two devices are well-matched. Baud rate will likely be slower than SPI though. But sometimes the application calls for a true full-duplex connection.

[ejeffrey]

(I have read some method of oversampling, but well, I hate this methodology......)(I am very unhappy about these async things

Honestly I suggest you just try to get over that.  Oversampling is not the only way to implement a UART receiver but it's almost always the best.  Or you can design a synchronous protocol but then it's not UART and can't communicate with a UART peripheral.

Note that in some implementations SPI slave peripherals especially in FPGAs use oversampling as well.  They don't clock their internal logic with the SPI clock but instead treat it as data input to a higher speed state machine.

[BrianHG]

Example Verilog UART.
Runs on 1 system clock.
Oversamples.
Also generates synchronizing TX output for high speed PC full duplex com.
Read and see documentation.

See here: https://www.eevblog.com/forum/fpga/verilog-rs232-uart-and-rs232-debugger-source-code-and-educational-tutorial/

(Skip the debugger part, you don't need that..)

[langwadt]

the over sampling in a regular uart does effectively do clock (phase) recovery, it is just rather coarse with only 16x/8x because no more is needed.
Classic full speed USB usually does it with 4x oversampling

[SiliconWizard]

Yes. Oversampling also takes care of resynchronizing clock domains (unless it's done very, very poorly), which is a must.

The one thing to understand when dealing with asynchronous communication and HDLs is clock domain crossing in general. If you don't even understand what this means, then designing a UART RX is almost certain to be a failure.

[BrianHG]

Just copy my code.
It auto over-samples to your system clock speed.
Adding a baud input control is easy enough by replacing the 'parameter' with a input port.

Only adding error support for 7bit even/odd parity will require an additional translation from the RXD byte and again for the outgoing TXD byte, but nothing else should change.

Also, adding hardware handshaking will require an additional gated input and output control por.

[PCB.Wiz]

(I have read some method of oversampling, but well, I hate this methodology......)(I am very unhappy about these async things(mismatching over baud rates, clock jitter, etc...) )...... I would rather does with I2C or SPI.
So how to achieve clock synchronizing over UART?(like the serdes's clock data recovery?)
maybe need some analog things (achieve some phase moving?) instead of RTL? (means that you need to pay some $ while making ASICs instead of working over FPGAs)

It's unclear what you are actually trying to do here ?  What does 'achieve clock synchronizing' mean ?

A UART peripheral is normally designed to talk to UARTS, that's implicit in its name.
It is time proven, and simple, but has some compromises.

UART oversampling used to be 16x, but these days you can find x8 and x4 designs, as vendors want to support higher Baud and lower sysclks.

Better UART peripherals allow fractional baud, giving more freedom on sysclk and baud choices, and expanding that higher bauds at lower clocks.
A common example these days is allowing 9600 Baud from 32.768kHz RTC clocks.  N = 3.413333333 here.

Some uart peripherals include Autobaud ability, to help insulate users form baud settings.

If you hope to create a x1 UART that 'locks' sampling with a x1 UART clock, such a design becomes very fragile, as not all UARTS have fixed stop bit quanta.
Better ones are gap-less and jitter-less, but I've measured many with fractional bit creep and jitter. 

Another UART does not care, but some fancy clock extraction design will need to tolerate that, which brings you back to xN oversampling. Simple and proven.
 

[antercreeper]

Yes!!

so it is why i hate it. And i would need a CPU running programs to send asciis over that.(Use RTL to handle those complicated FSM and exceptions is insane.)
My hole system is synchronized, only has some clock divider in the IO IPs. (If your design is very big, you still need to deal with it between different big IPs, however is under control.)
but I have to face this fact. :'(

[langwadt]

Yes!!

so it is why i hate it. And i would need a CPU running programs to send asciis over that.(Use RTL to handle those complicated FSM and exceptions is insane.)
My hole system is synchronized, only has some clock divider in the IO IPs. (If your design is very big, you still need to deal with it between different big IPs, however is under control.)
but I have to face this fact. :'(

you seems to be missing some very fundamental understanding of how a UART works and how it is impelemented

[antercreeper]

i agree with you. :'(

[SiliconWizard]

I don't know if your question was more a general one out of interest, or specific to the audio FPGA board you designed? I mean, is it this board that triggered your interest in FPGAs and HDLs, or is it a more general interest of yours?

Saying that, because for this audio board, purely using a beefy MCU (like the NXP iMXRT series) would probably get you way enough power for audio processing (unless you implement very intensive processing in the FPGA fabric as some coprocessor, that would otherwise not run as software) and wouldn't require all this knowledge about FPGAs and logic design, even for the most "basic" stuff like UARTs.

[antercreeper]

yes, a more general one, really because for a long time, i cannot understand the UART. :'(
for that audio board, it is a platform designed to implement my RTLs (for study purpose, or just for fun), instead of just finish some audio tasks, or be sold as a good on the shelf (Of course I have raspberrypi, which can very easily finish those things.)