Usselmann, Rudolf

USB 1.1 PHY

`ifdef USB_ASYNC_REST
always @(posedge clk or negedge rst)
`else
always @(posedge clk)
`endif
	if(!rst)		rx_active <= 1'b0;
	else
	if(synced_d && rx_en)	rx_active <= 1'b1;
	else
	if(se0 && rx_valid_r)	rx_active <= 1'b0;

always @(posedge clk)
	if(rx_valid)	rx_valid_r <= 1'b1;
	else
	if(fs_ce)	rx_valid_r <= 1'b0;


if PHY single end input easier to see 0, it is possible some short "se0" make rx_acive de-asserted, and later packet will loss. Suggest longer SE0(0.75~1.25 bit) before rx_active de-assert.

I think EOP need 2 bits SE0 has its reason. Because differential signal is more easier to be correct, but single-end signal is easier to be jammed/delayed/esd XXX

after modification, the PHY works directly with FPGA IO with much less packet loss.

SE0 length

I am using this USB 1.1 PHY (a VHDL translation) for an open-source project, and I ran into an issue. This only seems to happen when I use an USB HUB I
have (a chinese one, have not tested with other hubs though). It works OK when I connect to the host directly.

I'm using the PHY as an FS Device, using a simple external USB transceiver.

So, what is happening is I have an IN/DATA0 transaction that never gets acknowledged by the host. This causes retransmission of the same DATA0 ad-eternum.

Looking at the concrete data being sent, the only think that makes me believe it's causing this relates to CRC transmission ending with (binary) "00111111". I
suspect HUB is somehow expecting a stuff bit before EOP, and hence not reading the CRC correctly.

Section 7.1.9 of USB 2.0 standard states: "If required by the bit stuffing rules, a zero bit will be inserted even if it is the last bit before the
end-of-packet (EOP) signal".

This is also part of the USB certification Peripheral Silicon Checklist (http://www.usb.org/developers/compliance/check_list/), B6, section 3.1: "Is bit
stuffing performed even if the stuffed bit follows the last bit of a packet".

Here's my fix (basically delaying EOP by one FS cycle): 

<pre>
--- a/rtl/verilog/usb_tx_phy.v
+++ b/rtl/verilog/usb_tx_phy.v
@@ -317,7 +317,7 @@ always @(posedge clk)
 `endif
        if(!rst)        append_eop_sync2 &lt;= 1'b0;
        else
-       if(fs_ce)       append_eop_sync2 &lt;= append_eop_sync1;
+       if(fs_ce && !stuff)     append_eop_sync2 &lt;= append_eop_sync1;
 
 `ifdef USB_ASYNC_REST
 always @(posedge clk or negedge rst)
</pre>

bit-stuffing problem on last packet bit

I am implementing the PHY with dpll (using an NCO locked to sofs) and noticed if the clock frequency to the phy is too high a byte error can occur during reception of a sof packet.  If this happens the se0 can be be incorrectly decoded.  With no se0 rx_active doesn't get cleared ready for reception of the next packet. rx_active must be cleared so sync can be found and to restart the nrz decoder. Clearing rx_active when a byte_err occurs fixes this.

In normal operation I don't expect the frequency error to the phy to be large enough for the condition above to occur, however it surfaced during verification using unusual (out of spec.) sof timing.

byte error handling

Untitled bug

I have not tested it in hardware but I would liky to suggest something about the implementation of the DPLL. I have read a document from usb.org which has a possible finite state machine implementation. My question is why you did not used that?. Thanks in advance.

Browse

USB 1.1 PHY