|
Message
From: dmakwana@s...<dmakwana@s...>
Date: Thu May 6 12:57:15 CEST 2004
Subject: [usb] BUG in USB2.0 IP & One query
Dear Sir,
I am using the opencore IP for USB2.0 there I have found a bug
and also I have some doubts,
BUG:
"// After sending Data in response to an IN token from host, the
// host must reply with an ack. The host has 622nS in Full Speed
// mode and 400nS in High Speed mode to reply. RX_ACK_TO_VAL_FS
// and RX_ACK_TO_VAL_HS are the numbers of UTMI clock cycles
// minus 2 for Full and High Speed modes.
`define USBF_RX_ACK_TO_VAL_FS 8'd36
`define USBF_RX_ACK_TO_VAL_HS 8'd22
// After sending a OUT token the host must send a data packet.
// The host has 622nS in Full Speed mode and 400nS in High Speed
// mode to send the data packet.
// TX_DATA_TO_VAL_FS and TX_DATA_TO_VAL_HS are is the numbers
of
// UTMI clock cycles minus 2.
`define USBF_TX_DATA_TO_VAL_FS 8'd36
`define USBF_TX_DATA_TO_VAL_HS 8'd22"
Now for the full speed mode the parameter "`define
USBF_TX_DATA_TO_VAL_FS" has to be "`define
USBF_TX_DATA_TO_VAL_FS 8'd200" which is as per the timing spec.
Please correct me if I am wrong.
Doubt: I have my doubt in the enumeration process.
After reading the USB2.0 spec, each USB2.0 device must perform the
enumeration process in Full speed mode, now the core is architectured
as all the Devcie Descriptor data are passed through the Processor
sitting on the Wisbon bus,
Now in this core we have SRAM which is used by the both Core and the
processor/function, So in enumeration whatever Data like wValue,
Descriptor type, wIndex... are first stored in to SRAM and then the
processor/function reads this data and depending on the descriptor type
the processor/function writes the data in to the SRAM.
So the question is there is no interrupt to the processor/function from
the core which indicate specific for SETUP command form the device.
So in short How this IP support the enumeration process.
Regards
Deepak Makwana
Email : dmakwana@s...
|
 |
Browse
