- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello everyone,
Is there any way to reduce the error probability in a serial transmission using the UART provided by Altera? For a baudrate of 115200 bps there is a Pe = 0.001 (1 erronous byte each 1000 bytes). Maybe, to fix the error, the rate of the system clk must be different? Many thanksLink Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- there is a Pe = 0.001 (1 erronous byte each 1000 bytes). --- Quote End --- Where did you get this value? Is it your measurement? If so, for which direction? The value is extraordinary high and seems to indicate a hardware or software design error.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I use the uart provided by altera. The direction is from my pc sending bytes via serial port to the FPGA. The error rate is in the received bytes of the FPGA. Y just count when there is an error in the uart status register: if (status & (FIFOED_AVALON_UART_STATUS_PE_MSK | FIFOED_AVALON_UART_STATUS_FE_MSK)) { errors++; }- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is that meant to be the probability that a valid async character will treated as an error, or that random noise will be treated as a valid character?
A UART clock is likely to be 4 times the baud, and the middle 2 clocks of each bit time can be compared for equality - giving 10 bit pairs that must match per character. Except that the both samples of the stop bit must be zero, and the start bit (probably) has to last 3 samples. OTOH if your clock is slow you may not want to wait for all the stop bit (to avoid missing the next start bit). Or, a different sum. At 115k, a 4x clock is 460k, to guarantee a 1% (or better) clock you'll need to divide down from 50x460k or 23MHz. You need a 2.5% error on a 4x clock to get one clock out before the end of an async char - so 1% should be plenty! I suspect some standard will quote a closes tolerance though - it all depends on the way the UART logic is defined.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I guess, the frame format is N-8-1, so no parity errors should be detected. It would be interesting however to enable parity and check for real transmission errors.
I don't use Altera SOPC components and am not aware of the UART implementation details like bit sampling method and framing. If the UART is used for other purposes than occasional debugging, I won't accept the error rate. As dsl suggested, you should calculate the actual baud rate achieved with your SOPC clock frequency. In some cases, the timing error margin can be increased by sending an additional stop bit from the peer.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am using the uart corresponding http://www.alterawiki.com/wiki/fifoed_avalon_uart
My system clock has a frequency of 144 MHz, enough for sampling the serial line. Also, in my tests, it is achieved the maximum baud: In the FPGA the elapsed time between receiving the first character until the last is 1250 ms, when I transmit 14400 characters in the computer. (14400 characters * 10 bits/character) /115200 (bits/sec) = 1250 ms The error in the status register comes when: assign rxd_shift_reg = unxshiftxrxd_shift_regxshift_reg_start_bit_nxx6_out; assign {stop_bit,raw_data_in,unused_start_bit} = rxd_shift_reg; assign is_break = ~(|rxd_shift_reg); assign is_framing_error = ~stop_bit && ~is_break; always @(posedge clk or negedge reset_n) begin if (reset_n == 0) unxshiftxrxd_shift_regxshift_reg_start_bit_nxx6_out <= 0; else if (clk_en) unxshiftxrxd_shift_regxshift_reg_start_bit_nxx6_out <= unxshiftxrxd_shift_regxshift_reg_start_bit_nxx6_in; end assign unxshiftxrxd_shift_regxshift_reg_start_bit_nxx6_in = (do_start_rx)? {10{1'b1}} : (sample_enable)? {sync_rxd, unxshiftxrxd_shift_regxshift_reg_start_bit_nxx6_out[9 : 1]} : unxshiftxrxd_shift_regxshift_reg_start_bit_nxx6_out; assign rx_in_process = shift_reg_start_bit_n; assign sample_enable = baud_clk_en && rx_in_process; ... I suppose the error comes when a bit is out of sync, probably one of the last bit of the 10 sampled bits.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, so the receive async stream is back-to-back 10bit characters?
ie no extra delays between the stop bit of one character and the start bit of the next? If so it might be that the UART doesn't allow for a short stop bit - which is needed if the transmitter's clock is running slightly faster than the receiver's. The baud rate divisor might be being 'rounded to nearest', instead try rounding it down - giving a very slightly fast clock. This should mean that a clock of 'line idle' appears after some stop bits. Hopefully, when you transmit, the receiving hardware works better!- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, I understand , maybe i will test with two stop bits in the tx for making the system more stable.
Many thanks.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tx with 2 stop bits and rx with one.
Actually I doubt anything checks the number of rx stop bits! (Unless you've got an ASR33 lurking!)- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The error probability is reduced:
In this case I have transmitted 1004409 characters and there are 34 erronous. Pe = 34 / 1004409 = 0.000038- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've just considered 1bit async (each 'char' is 0x1) using a 4x clock.
A start bit sampled at t(0) might have happened just after t(-1) so the next transition might happen before t(3) or after t(4) - so we must not sample t(4n-1) or t(4n). t(1) and t(2) are the rest of the start bit - must be zero. t(5) and t(6) are the data, and must match. t(9) and t(10) are the stop bit, both must be 1. t(11) might be the start bit for the next character. Really shouldn't be that hard! I've just corrected the async format. Another uart spec I have uses 8, 16 or 32 times clock checking the middle 3 samples.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Time to write your own uart :-)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks. I'll consider it :)
I 'll comment any progress!- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hmmm.... The standard Altera UART seems to only have a 1x clock input. Even if it uses both edges that isn't enough to (easily) decode async.
The fifo uart only seems to have pre-defined baud/divisors, so it is difficult to verify from the docs. If the data isn't oversampled then it will go wrong.- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page