According to the UTMI spec (page 31), the state of the TxReady pin
is undefined in the TxWait state (see figure 12). Given that, I
believe the following code will block the K Chirp generation if the
UTMI interface has the TxReady signal asserted to a 1 by default.

always @(posedge phy_clk)
if(TxReady || tx_first) DataOut else
if(drive_k) DataOut
I suspect it should actually be
always @(posedge phy_clk)
if(drive_k) DataOut else
if(TxReady || tx_first) DataOut
Any thoughts on this?

John Providenza

On Tue, 2005-12-27 at 21:50 +0100, johnp at probo.com wrote: I think the change should be ok. rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and Synthesis ****** Certified USB 2.0 HS OTG and HS Device IP Cores ******

I can confirm that this change is essential for proper operation. A few months ago, I noticed this issue (and made the same exact change) when the USB 2.0 function core was failing enumeration with a USB 1.1 host when connected through a hub. I have only seen the problem with one particular host while using a hub, and it failed about 30 percent of the time. Prior to the change, I had never seen the core fail during enumeration with any USB 2.0 host (with or without a hub). I've been using this particular change (many devices, many different host controller and hub combinations) for about 6 months and have encountered no problems as a result of it. On 12/28/05, johnp at probo.com johnp at probo.com> wrote: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/usb/attachments/20051228/8b29eab7/attachment.html