I just implemented a simple UART transmitter (10 flops + timing generator), and am looking at the receiver. As a compulsive minimalist, I am offended by the elaborate and enormous 'examples' I've seen. The receiver seems trickier than the transmitter register, but is it really?

I believe that modern devices are likely to have very stable timing, so things like 16x oversampling (or any oversampling) is an overkill. A straightforward shift register with a 1/2-bit start delay should stay in sync for the remaining 8 bits.

So the tricky parts:
* detect 1-0 start bit transition (and ignore other such transitions), which requires two states - idle and busy, and the associated counter for asserting the busy state while shifting;
* set the timing counter to 1/2 the total baud-rate count, to assure sampling mid-bit;
* enable the shift register and busy-state bit and bit counter;
* don't forget to shift out the start bit (count to 8 to 0?)
* upon transition to idle, stop shifting, buffer the data and signal 'data ready'
* if you want to be fancy, check for stop bit and signal 'framing error'

This seems pretty minimal.

Does anyone have experience implementing UARTs for FPGAs?

TLDR: got something working here:
https://tildegit.org/stack/Tangnano9K-UART

There's a simple UART (a page of verilog) in the OPC project (which is GPL-licensed although the file has no comment to that effect.) It's probably the work of hoglet, or possibly revaldinho.
https://github.com/revaldinho/opc/blob/ ... src/uart.v

Also, Bill Shen (Plasmo here and on RetroBrew) has implemented a UART in the Altera EPM7064S... he uses it on his CRC65. You can find his project here:

https://www.retrobrewcomputers.org/doku ... rc65r2home

_________________
Regards, KM
https://github.com/floobydust

OPC's UART is pretty compact. My transmitter is a bit shorter and simpler, I think. I think I could live with OPC's receiver...

@floobydust, I think the link you sent me does not have a UART -- on the schematic, at least, it only shows an I2C port...

verilog can be misleading -- a page of verilog can potentially generate an enormous circuit! It's pretty easy to miss things like unhandled conditions which generate tons of latches, etc.

I built up one of Bill's original CRC65 boards... and it's running as a UART at 115,200 N-8-1 via a USB/UART adapter. Perhaps looks at the build files... which requires the older Quartus II tooling.

_________________
Regards, KM
https://github.com/floobydust

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

This is the UART receiver I used for several years. It is in Altera schematic, about 20 flip flops. It does have 16X clock and sample in mid-bit.
Bill
download/file.php?id=14303&mode=view

Schematic is from the CPLD trainer topic, viewtopic.php?f=10&t=6974&p=90671&hilit=74165#p90670

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I have what is supposed to be a 6551 compatible uart. It is about as complex as need be. It does sampling and majority logic on the bit receive. It also has fifos. It is <400 LUTs. There are a couple of top level interfaces, one with component discovery.

An issue with the timing is that the hosts and device clocks may not be exactly the same rate. So for a long stream of bits I think the 16x(or 8x) clock with resyncing is needed.

https://github.com/robfinch/Cores/tree/master/uart6551/trunk

_________________
http://www.finitron.ca

I've implemented successful UART receivers using just a timer in software running at four times the baud rate. The clock testing the receive start bit has to happen multiple times during each bit to allow a close hit to the centre of the start bit; that's then doing the sampling in the middle of successive bits by using a single bit delay after the initial start.

Running the clock at 16x baud means the first bit will be within 1/16th of the centre, and successive bits can be 2.5% fast and still hit in the active part of the sample on the last bit. 4x baud has tighter timing requirements for the transmitter.

If you're detecting the falling edge of the start bit, then you can use a x2 clock (or a simple delay) to find the centre of the first bit. The x16 is used - as Garth indicates - to give best-of-three centre samples in hardware which does such things. I've never found it necessary; as also pointed out above, we tend to use short cable runs in generally noise free environments, and in most cases I suspect using serial-usb adaptors which are effectively tied to the 24MHz USB clock; drift is not an option. I don't usually bother with frame error detection; it just doesn't happen on such systems.

What you do need to remember is that the two clock rates have to be within +/- 2.5% for the sampling to work for the last bit and the stop bit. That is independent of the baud rate...

Neil

Just a note on matching or mismatching clock rates at sender and receiver
- crystals are really very accurate
- but sometimes a pragmatic design takes a high frequency and divides it down to something rather near to the ideal value. This clock will be precisely inaccurate.
- sometimes we encounter bit-banged senders or receivers, which can only manage some approximation of ideal timing

Never having built an FPGA UART, I have had very good results implementing serial Rx/Tx in software - bit-banged in the output, timed sampling on the input. Results have been good to 19200 baud on a 2Mhz system. It does need good timing loops and cycle counting though.

I don't think my code has been anything special - no oversampling:

Wait for the next High to Low transition (Don't bother checking for line idle for any time, just the next High to Low to indicate a potential start bit)

Delay 1.5 bit times.

Repeat 8 times:
- Read input pin, shift into input register
- Delay one bit time

Do a final read of the input pin - if it's not High then we have a framing error

And that's basically it.

I know of one that will read data at 115200 baud on a 2Mhz 6502 but the code is quite special for that as timings are vanishingly small at that rate.

If I were doing it in hardware, then the hardware doesn't need to check parity or framing - just present the data to the program doing the reading. So a bit goes high in the status register after you clock in those 8 bits to indicate "ready" (bit is cleared on a data register read) Another bit is simply the 9th bit - the stop bit (so if software reads it high then it can simply ignore the data and read another byte) Parity can be calculated by feeding the input bits through an XOR stage and present the output as another bit in the status register - again hardware doesn't need to check as the software can check the polarity of that bit against what's expected.

Maybe this makes for a far-too-simple UART but for simple console/terminal IO do you need more?

I can download code into my 6507 SBC with a software UART without any real issues, although with no flow control I need to reduce the baud to 9600 and get the sending program to delay at each CR sent but that's all that's needed for me here.

So it'll be time vs effort at the end of the day, I suspect.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thank you for informative responses!

My own clock is actually 27MHz, with a count of 234 the baud rate comes out as 115384.6, close enough for rock and roll. At some point I'll get a PLL working, and if I had to I could jitter out the UART clock to correct, but whatever. I should probably do the math to figure out how much of an error I can take, but I really think starting midway I can get 8 bits in consistently (especially since I am talking to a very specific chip on-board.

I'm also not concerned with noise, as the RS-232 signal has to travel about 8mm to the USB chip. The USB chip, btw, is a blackboxed RISC-V SOC pretending to be one of those cheap USB-serial chips. I guess they can make those even cheaper!

I'll report when I get something working.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!