Edge Cases & Debugging

What happens if the CPU reads RX_DATA while the RX FIFO is empty?

Data_Out combinationally shows whatever stale byte sits at the read pointer slot, and the AXI read returns it with OKAY. The pointer does not move because the pop is gated by !Fifo_Empty inside the FIFO. The contract is that software checks the Rx_Ready status bit first, and that is documented in the README.

What happens on the AXI read that pops the last byte, making the FIFO empty?

That read is fully correct: the head byte is returned, the pointer increments, and Rx_Ready drops combinationally as the pointers become equal. Only a subsequent read without new data returns stale contents.

What happens when a FIFO push and pop land on the same clock edge?

Both pointers advance, occupancy is unchanged, and no data is corrupted since the write targets the write slot while the read pointer moves independently. The RX testbench has a dedicated check that streams bytes with Pop_Enable held high to force this and verifies the FIFO drains cleanly with no overrun.

An AXI master completes the AW handshake, drops AWADDR, and sends W data three cycles later. What happens?

The wrapper wrote Write_Address_Q at the AW handshake, so the commit decodes the latched address and the write lands correctly. Before I added the latch this exact sequence wrote the data into whatever register the floating address bus pointed at; my testbench reproduces it with an intended address and a decoy.

What happens if software writes TX_DATA while the TX FIFO is full?

The wrapper still pulses Tx_Push_Enable and returns OKAY, but the FIFO push inside Uart_Tx is gated by !Tx_Full, so the byte is silently dropped. Software is expected to check Tx_Full or occupancy in STATUS first. Returning SLVERR or an interrupt would be the hardening step.

How much baud rate mismatch can the receiver tolerate?

Sampling is re-anchored at every start edge, so error only accumulates across one 10-bit frame. The last sample drifts about 9.5 bit-periods times the mismatch, and it must stay within roughly half a bit, giving on the order of 4 to 5 percent total mismatch, minus the 1/16-bit oversampling quantization. The loopback test shares one clock, so drift tolerance is argued from design, not proven in that sim.

A short low glitch hits the idle RX line. What happens?

The FSM enters Start and counts to the middle of the supposed start bit. The recheck sees the line high again, so it returns to Idle without shifting anything. Only a low that survives half a bit period is treated as a real start bit.

What happens when the stop bit arrives low?

Frame_Error is set at the stop sample, Byte_Valid still pulses, but the push is gated by !Frame_Error so the corrupted byte never enters the FIFO and the write pointer is untouched. The testbench does this for all 256 byte values and verifies the pointer never moves.

Does Frame_Error stay set forever after one bad frame?

No. It is reassigned at every stop-bit sample, so the next clean frame writes it back to zero. It reflects the status of the most recent frame; software that needs latching behavior would read it promptly or the wrapper would need a sticky version.

What happens on reset in the middle of a TX frame?

The async reset forces the state to Idle, clears busy and both FIFO pointers, and the line returns to idle high immediately because the Tx flop is an FDPE that presets to 1. The TX testbench resets mid-frame and checks state, pointers, and busy all recover.

What happens to the 17th byte arriving at a full RX FIFO?

It is lost. The completed byte cannot be pushed, Over_Run_Error goes high, and it stays high until some later byte is successfully written. The testbench fills the FIFO with 17 frames and checks the flag asserts.

Can a second AXI write start while the first one's B response is still pending?

No. The Done flags stay set until Bvalid && Bready completes, and AWREADY/WREADY are only granted when the flags are clear, so transactions serialize. A new AR during a pending Rvalid is likewise ignored until Rvalid clears.

Your simulation hangs waiting for Bvalid. How does the testbench handle it and what subtle bug did you fix there?

The wait() never returns, so the concurrent watchdog fires at the timeout, ends the sim, and prints the summary. Originally the watchdog did not set any error flag, so a hung run printed ALL TESTS PASSED with untouched counters. I made it set Error_Timeout first so a hang is reported as a failure.

Tell me about the width typo you caught and how it showed up.

I declared Write_Data_Q with Address_Width, 4 bits, instead of Data_Width, 32. Writing 0x41 to TX pushed 0xx1: the low nibble survived, bits 7:4 read as x. Copy-pasting the adjacent declaration changed the name but not the width. The register-level testbench caught it immediately because the pushed byte was checked against the exact value.

Why does the loopback test use bytes like 0x55, 0xAA, 0x01, 0x80, 0x00, 0xFF?

Each pattern targets a failure class: 0x55/0xAA catch bit-order swaps and adjacent-bit shorts, 0x01/0x80 catch off-by-one errors at the frame edges, 0x00/0xFF catch stuck-at lines and framing confusion with start and stop bits. Eight passes mean bit order, framing, and both FIFO paths are all correct end to end.

Why do the testbenches run at 5 Mbaud with a divider of 10 instead of 115200?

Only to compress simulation time: 10 clocks per bit instead of 868 makes a full frame about 1 microsecond, so the whole loopback runs in about 18 microseconds of sim time. The RTL is identical; baud is a parameter override in the testbench only.