Re: [usb] RXValid signal

["Luis J. Perez" <luis.perez@ds2.es>]

> santhi lakshminarayanan wrote:
> 
> Hello,
> 
> Please find the answers below:
> 1.  a) A bit stuff error occurs during reception, when a consecutive 6
> "1"s in the data stream is not succeeded by a '0'. This indicates that
> a bit stuffing has not occured at the transmitting end or some
> corruption has occured in the reception. Either case, it is an error
> detected due to bit stuffing in the reception.


I supposed that.


>       b) 8 stuffed bits are accumulated over a continuous data stream,
> but may not be consecutive. There can be 6 '1's and a '0', followed by
> a different pattern which does not require bit stuffing, and then
> another 6'1's and a '0' which makes the count of unstuffed bits to
> increment and so on.


Not necessarily consecutive, Thanks. But... why must be skip a byte
(negate RXValid) after 8 stuffed bits?
I will do this way (using a counter), but I don't understand the sense
of this...

Another related question: when a bit is stuffed I must skip ONLY THE
STUFFED BIT or THE WHOLE BYTE tha contains the stuffed bit?
Example: 
RXD ->  K J K J K J K K J J J J K J K J K J K K K K K K K J J J J K K J
K 
NRZI -> 0 0 0 0 0 0 0 1 0 1 1 1 0 0 0 0 0 0 0 1 1 1 1 1 1 0 1 1 1 0 1 0
0
UNST -> 0 0 0 0 0 0 0 1 0 1 1 1 0 0 0 0 0 0 0 1 1 1 1 1 1  1  1 1 0 1 0
0
							   !
							unstuffed

Is that correct?

> 
> 2. In FS mode, ideal number of CLK cycles per byte time is 40 (which
> can be 45 or 50 for 1 or 2 bit stuffs respectively). RXValid is
> asserted only one CLK cycle per byte time where we need to ensure that
> data is also valid on the data bus. Till next data byte is available
> RXValid will not be asserted, Following the state machine, RXValid is
> asserted whenever RX Data state is entered.


Well, 40 cycles when you use a HS/FS transceiver (a 60MHz clockout), but
when using only FS mode this clockout must be 48 MHz, and then will be
32 cycles (anyway this clockout could be 12 MHz, and it will suppose
only 8 cycles). So I think this FSM must work at the same clock
frequency as the clock you drive to the Device Core (the data you sent
will be sampled at THIS frequency). Then, using a 48MHz clock, it would
be 36 or 40 for 1 or 2 bit stuffs respectively, I think.
So, if RXValid will be asserted each time the RX Data state is entered,
I must enter THIS state only when the RX hold register is full (1 byte
ready), and then go to RX Data Wait during at least 7 cycles (to refill
again the hold register)...
Is this tha way it works?


> 
> 3.  !Data indicates that data is not available to be sent on the data
> bus. This could be because of bit unstuffs or as in the case of FS
> mode, where data is available only once in 40-50 CLK cycles (and for
> the rest of the CLK cycles, data is not available).
> 


OK, so it's the same as the 2nd answer: "!Data" = bit unstuff, or RX
hold reg is not full..., isn't it?


> I hope these answers your questions.
> 
> Regards,
> Santhi.
> 

Thanks Santhi,
--
To unsubscribe from usb mailing list please visit http://www.opencores.org/mailinglists.shtml