Hi All,
I’ve an uart hardware implemented on Xilinx FPGA image and it connects
to host CPU(Intel based chip) on PCIe bus in Linux platform.
The following parameters were fixed or varied when measuring the UART
throughput in internal loopback mode(UART_RX and UART_TX pins were
internally connected):
• Uart baud rate
• Parity Bit
• Stop Bit(s)
The primary factor affecting UART throughput is the baud rate, apart
from this any other factors affect the UART throughput?
For 4000000 bps uart baud rate, what should be the theoretical peak
data throughput?
--
Thanks,
Sekhar
On Thu, Apr 05, 2018 at 10:08:14PM +0530, Muni Sekhar wrote:
> Hi All,
>
>
> I’ve an uart hardware implemented on Xilinx FPGA image and it connects
> to host CPU(Intel based chip) on PCIe bus in Linux platform.
>
>
> The following parameters were fixed or varied when measuring the UART
> throughput in internal loopback mode(UART_RX and UART_TX pins were
> internally connected):
>
>
> • Uart baud rate
> • Parity Bit
> • Stop Bit(s)
>
>
> The primary factor affecting UART throughput is the baud rate, apart
> from this any other factors affect the UART throughput?
>
> For 4000000 bps uart baud rate, what should be the theoretical peak
> data throughput?
Um, you do know what "baud rate" means, right? And how stop bits and
parity are related to a baud rate?
Throughput all depends on a whole raft of different things. How exactly
have you measured this and where did you find any performance
bottlenecks?
thanks,
greg k-h
> The primary factor affecting UART throughput is the baud rate, apart
> from this any other factors affect the UART throughput?
UART
CPU power
interrupt latency
all the usual suspects.
> > For 4000000 bps uart baud rate, what should be the theoretical peak
> data throughput?
>
Depends entirely what the uart is wired to, how it works and how the
driver is written. If you've got bidirectional communication going on
then you also need to consider latency and windowing.
For a raw transfer over a decent UART with DMA with no post-processing I'd
expect you can do the full line rate but it may eat a lot of CPU time.
The uart code isn't particularly optimal for that kind of usage. It's not
impossible to fix by fast-pathing the non N_TTY line discipline cases but
nobody has found it a big enough pain to bother.
Alan