PORTS Forum
Ports and Interfaces => USB => Topic started by: ChongHan on May 09, 2014, 12:03:55 am
-
Hi all, I have several question about SuperSpeed Clock.
1) Host's bus interval clock is different to each active devices?
2) How to add a external clock to a SuperSpeed USB system. Just install it as a peripheral device that provide clock for host and other devices?
3) Bus interval boundary is mark using a clock tick, and ITP is send at each boundary of bus interval's boundary according to the same clock tick that create the bus interval's boundary? Between. how to check/explore host's clock and device's clock?
Thanks in advance.
Regards
Chong Han
-
A host uses the same bus intervals for all devices on the bus.
You can use an external timing source or derive a clock from an timing source if available.
What are you trying to accomplish? What problem are you attempting to solve by checking the host's clock and device's clock?
-
1. I don't know exactly what the spec is, but I'm pretty sure the implementations I worked on used the same clock for each device.
2. Again, I don't know if the spec allows it, but the implementation I worked on did not allow for this.
3. I don't know what the question is here.
As Jan said, what's the actual problem you're trying to solve. I think you're probably headed in the wrong direction.
-
My understanding is that the only "clock" you can control is for the entire bus, not a single device. And, even then, you are not actually controlling a clock -- you are simply adjusting how many clock oscillations occur between USB Start-of-Frame packets. You normally do not need to mess with this timing at all,
unless you are trying to synchronize/slave the USB bus to some external timing source.
I didn't realize you could even use an external timing source, though I suppose some hardware implementations could allow for that. The only hardware I've ever seen has an oscillator built onto the card/motherboard.
As Jan and Barry stated, you should probably clearly state the actual problem you are trying to solve. If you are needing some sort of highly synchronized or highly precise timing characteristics, USB may be ill-suited to the task.
-
"you are simply adjusting how many clock oscillations occur between USB Start-of-Frame packets".
My actual problem is something like above statement but is in USB 3.0. To adjust the how many clock oscillation, I need to know how is the clock is (but how to check host's clock?). How the host create a bus interval using the clock. How many period of clock in a bus interval.
Is that the bus interval of all connected devices is same to each other and also same in both IN and OUT direction?
-
You still haven't said what the actual problem you're trying to solve is. I don't think you're going to get anywhere with your current thinking.
Are you considering using the Bus Interval Adjustment Message? (As specified in 8.5.6.6.)
You should note in the 3.1 spec it says:
The Bus Interval Adjustment Message may be sent only by devices operating at Gen 1 speed and shall be ignored by hosts that are not operating at Gen 1 speed. Note that this notification will be deprecated in a future release.
I was surprised to see it included in the spec, similar language was included in the 1.x spec, and then not included in the 2.0 spec, so I thought the idea was dead. It looks like they're trying to kill it again. I'm not aware of any host which implements the message, I know our host implementation didn't.
It seems pretty clear to me reading that section that the BusIntervalAdjustmentGranularity unit is not specified at the device is required to see what happens when it changes the bus interval and work that out itself.
If no host implements the message, then you're not going to see any adjustment.
-
Yes. But i want to try it for using this Message.
Yes I know too the USB3.1 Spec already stated that it will deprecated in future release. So i am planning to do only in USB 3.0 host and device' controller only.
So this function is stated in the USB3.0 Spec. Therefore it should work in practical right? Just maybe it can't be too precise. Am I right?
And for now, I am actually didn't know about the bus interval in USB. How they create bus interval, and why to use it. If using clock, then how the clock create the bus interval in USB bus?
Thanks everyone in advance.
Best Regards
Chong Han
-
You still haven't said why you want to use the message. What problem you're trying to solve. I don't think its going to work.
As I said, this may very well be not implemented on the host. I didn't implement it on the host stack I worked on. I would be quite surprised if you did find a host on which it was implemented.
I don't understand the rest of the question. The bus interval is defined as 125µs, which is a hold over from USB 2. Its there to give isochronous devices a clock. The rest sounds like you're asking for implementation details, which you shouldn't be concerned with, and by definition depend on the implementation.
-
Hi
I want to use these message to synchronize multiple device which I can trigger them in the same time. Therefore I want to adjust bus interval so that all the command from the host will reach all the connected devices to start work at the same time.
For the host controller, how can I know it support the Bus Interval Adjustment Message or not?
Thanks.
-
If all you want to do is synchronise devices why are you worrying about adjusting the bus interval? The ITP is broadcast to all devices with the intention of providing synchronisation. It would seem to do exactly what you want without messing with the timing.
To receive ITPs you have to make sure the link is in U0, and don't take any notice of ITPs with the delayed bit set. That's about it.
The host controller must support the Bus Interval Adjustment Message, but the host software doesn't have to do anything with it. (My software just logs the message, and ignores it.) The only way you'd know if the host software is doing anything with it is if the bus interval changes.
-
Hi
Transmission of ITP is via control endpoint or isochronous endpoint?
So ITP provide timing for synchronization of between multiple devices to, but not only one to one between host and device. Am i right?
Any method I can use to check the ITP packet transmission activity?
Thanks in advance.
-
The ITP is not transmitted to any endpoint or to any device. Its a packet which is broadcast to all devices.
I don't understand the rest of the question.
You can check the ITP packets with a bus analyser, like any other packets on the bus.
-
So the ITP will be multicast to all devices automatically and we no need to ask host to send?
How can I derive the timing info from ITP in device if there is no endpoint to receive it?
-
The ITP is sent automatically to all devices with links in U0.
The device has to know how to receive the packet, much like USB1/2 devices take note of SOFs. You may find your device chip has a register which tells you the value of the last timestamp received.
-
Hi me again.
Thanks again to all for answering my question. So for synchronization, we just need to use the info from ITP?
The ITP mark the timestamp when packet leave the host. So from the device's side, we just compare the timestamp which receive the ITP packet with the value in ITP right? Therefore we can use the calculated result to adjust the clock tick(period) in the device right?
-
That's the idea.
I see that the 3.1 spec has a whole extra bit about timestamps. It looks like its a lot more thorough on the sort of thing you're wanting to do. I don't know how much of this will apply to 3.0 hosts, which are the majority of hosts you're likely to find.
-
Hi
Me again. Do you all have some screenshot for ITP timestamp packet? A continuous ITP packet?
Is the Delta value in the ITP is fix for each link? Or it will change time by time or interval by interval?
Thanks in advance.
-
Do you all have some screenshot for ITP timestamp packet? A continuous ITP packet?
A screen shot of what? Its fig 8-31 in my copy of the 3.1 spec. I don't have any super speed analyzer traces available. I don't know what you mean by "continuous ITP packet".
Is the Delta value in the ITP is fix for each link? Or it will change time by time or interval by interval?
Of what you mean by the Delta value.
-
A screen shot of what? Its fig 8-31 in my copy of the 3.1 spec. I don't have any super speed analyzer traces available. I don't know what you mean by "continuous ITP packet".
Yes. I have the Spec too. However in spec it just shows the theory only. As now i dint have any Hardware SuperSpeed analyzer, I can't really see the exact practical value in the ITP packet. How it's look like in real transfer.
Of what you mean by the Delta value.
According to the spec, the delta value is the value between the bus interval boundary and start of ITP transmission by root hub port. I check it myself by programming the Cypress DVK by sending the ITP back to host by Bulk transfer. Then at the host side, i use the SuperSpeed Software Analyzer to see the data received by host. For this, i see that the Bus Interval Counter is counting 1 by 1, but the ITP delta is always zero. The problem nw is there will a random bus interval has a non-zero delta value. From spec, the ITP is transmitting periodically, so from my understanding, the delta should be same for all bus interval, if delta unit is 1, then all remaining delta should be 1 too. Now the delta is randomly have a non-zero delta value in random bus interval, delta is other Bus interval is zero at all.
So I am seeking for prove is that my understanding is right or not. Creating Bus interval and ITP is periodically in 125us(8kHz).