OPENCORES.ORG

`USBF_T1_C_3_0_MS). However idle_cnt1 increments every 250ns, and

  I did a little testing of the USB 2.0 core a while ago, and also
noticed the usb_vbus_pad_i problem.  The Verilog code expects
ubs_vbus_pad_i to be a negative true. (don't ask me why, seems incorrect
to me) So, you can either tie it off low, or invert it once it comes
into your chip. (I did the latter)

  I also noticed that there is something strange with the millisecond
"T1" timers in usbf_utmi_ls.v. (T1_st_3_0_mS, T1_gt_3_0_mS, etc) There
are two counters used to calculate time:

  ps_cnt : increments every clock cycle (16.7ns), resets after 15
cycles. (15*16.7ns=250 ns)

  idle_cnt1 : increments when ps_cnt resets (250 ns), resets after 250
cycles (250*250ns=62.5us)

  Now take T1_gt_3_0_mS for example. If I understand the naming
convention correctly, we want this counter to go high after ~3.0mS.
According to the logic in usbf_utmi_ls.v it will go high when (idle_cnt1
> `USBF_T1_C_3_0_MS). However idle_cnt1 increments every 250ns, and
USBF_T1_C_3_0_MS is only defined as 48. (48*250ns=12us)

  If you look the comments where USBF_T1_C_3_0_MS is defined, it looks
like USBF_T1_C_3_0_MS was expecting to be based off of 62.5us counter.
(not the 250ns counter, idle_cnt1)  So, in my design I created an
idle_cnt2 that incremented every 62.5us, and used that as the counter
for T1_st_3_0_mS, T1_gt_3_0_mS, T1_gt_3_125_mS, and T1_gt_5_0_mS.

  My lingering questions were: What should I use to reset this counter
and what should its upper bound be.  As it stands now I use...

reg [7:0] idle_cnt2, idle_cnt2_next = 8'h0;

// Count 62.5 uS
always @(posedge clk)
  if(!idle_long || idle_cnt_clr)
    idle_cnt2 <= 8'h0;
  else if(!T1_gt_5_0_mS && ps_cnt_clr)
    idle_cnt2 <= idle_cnt2_next;

always @(posedge clk)
  if(!idle_long || idle_cnt_clr)
    idle_cnt2_next <= 8'h0;
  else if (idle_cnt1_clr)
    idle_cnt2_next <= idle_cnt2 + 8'h1;

but my reset for idle_cnt2_next and idle_cnt2 are just based off of the
idle_cnt1 logic. I also don't have an idle_cnt2_clr, but one might be
needed.  Maybe Rudi could comment, or if someone has time to experiment
or understand the finer points of this file. (I was trying to figure it
all out, but have been switched to more pressing tasks)

  That fix helped my design considerably, but the core still wasn't
receiving the GetDescriptor packet from the Host.  This turned out to be
because the "Main State Machine" in usbf_utmi_ls.v was jumping to the
RESET state from the NORMAL state whenever I received any packet. (even
the SOF packets)  As a hack I commented out the logic to jump from
NORMAL to RESET and the core receives the GetDescriptor packet
correctly.

 Unfortunately (just when it was getting interesting) I had to shift to
something else and won't be able to go back for a while.  I don't know
if any of this is helpful to anyone, but here it is anyway.

  All of my testing was done in FS. For some reason my HS Speed
Negotiation failed and reverted to Full Speed. (have to check that out
too, some day)

Brian

-----Original Message-----
From: usb-bounces@o... [mailto:usb-bounces@o...] On
Behalf Of dmakwana@s...
Sent: Thursday, May 27, 2004 5:00 AM
To: usb@o...
Subject: Re: [usb] Ask a help on

Dear Mr. NI haiqiao, 

  Yes, you are true, even I have found the same thing during hardware 
testing of the USB2.0 IP. 

  The only solution to this is just to hardcode the usb_vbus_pad_i
signal 
to "0".

   Currently I am in stage of testing the core and I was suceessfully 
passed the Speed Negotiation phase and the host perfectly responded 
for High Speed device with Chirp KJKJKJ sequence, and after that I am 
also geting SOF command in high speed mode, but them some thing 
happens to the core and I am not getting SETUP command for "Get 
Descriptor".

   Please help me if have passed the Enumeration pahse for USB2.0 IP.

Thanks & Regards

Deepak Makwana
dmakwana@s...

----- Original Message ----- 
From: nihq@r... 
To: usb@o... 
Date: Sun, 12 Jan 2003 04:52:08 -0100 
Subject: [usb] Ask a help on 

> 
> 
> Dear expert: 
> 
>      I cannot understand How the usb_vbus_pad_i (Vcc of USB 
> connector) of UTMI interface effect the attached flag. 
> 
>      I look look through the usbf_utmi_ls.v and find that if Vcc ( 
> here is usb_vbus) is always logic "1", then the the machine state 
> is 
> always in powon or reset state. 
> 
> always @(posedge clk or negedge rst) 
> 	if(!rst)		state <= #1 POR; 
> 	else 
> 	if(usb_vbus)		state <= #1 POR; 
> 	else			state <= #1 next_state; 
> 
>     But you know the usb_vbus (Vcc) is always logic "1" when the 
> usb connector is powered. Then the usb_core will never work to 
> the useful state. 
>     Could any expert give me a hint? 
> 
>     Thank Vikas T Rao for your previous answer! 
> 
> best regards 
> NI haiqiao 
> 
_______________________________________________
http://www.opencores.org/mailman/listinfo/usb