TUSB2E221QFNEVM: When TUSB2E221 is configured as a device repeater, does the eUSB2 device need to support CM?

Hello,

Andrew Chien said:

Does the eUSB2 device need to communicate with TUSB2E221 by CM?

Section 5.4 of the eUSB2 spec goes into detail on the commands and signals needed for peripheral orientation with an eUSB2 repeater. Going by the spec, CM lines are not required to configure the repeater as a device/peripheral.

Andrew Chien said:

Our eUSB2 device only support FS speed, could the configuration be done by I2C or GPIO?

Yes, only I2C or GPIO can be used to configure the repeater. CM.RAP functionality is not required to configure EQ or other configuration settings.

Thanks,

Ryan

Hello Ryan,

Thanks a lot for your elaboration.

Ryan Kitto said:

Section 5.4 of the eUSB2 spec goes into detail on the commands and signals needed for peripheral orientation with an eUSB2 repeater. Going by the spec, CM lines are not required to configure the repeater as a device/peripheral.

In Figure 5-11, CM.Lx/CM.FS is used to change the state from L0 to Lx, will TUSB2E221 use this CM in Device repeater mode?
We planned not to implement CM in our device, could the device just stay in L0? 

BTW, the "Bus Reset" in peripheral mode does not need to use CM.Reset, is my understanding correct?

Ryan Kitto said:

Yes, only I2C or GPIO can be used to configure the repeater. CM.RAP functionality is not required to configure EQ or other configuration settings.

I2C can be used to configure the repeater to device repeater via CONFIG_PORT0/CONFIG_PORT1 register, is my understanding correct?

Could you also tell us how to configure the repeater to device repeater by GPIO?

Hi Andrew,

Andrew Chien said:

In Figure 5-11, CM.Lx/CM.FS is used to change the state from L0 to Lx, will TUSB2E221 use this CM in Device repeater mode?
We planned not to implement CM in our device, could the device just stay in L0? 

BTW, the "Bus Reset" in peripheral mode does not need to use CM.Reset, is my understanding correct?

After reviewing the eUSB2 spec, it does look like CM is needed for specifically FS operation. Section 5.4.4 details this:

Andrew Chien said:

I2C can be used to configure the repeater to device repeater via CONFIG_PORT0/CONFIG_PORT1 register, is my understanding correct?

Could you also tell us how to configure the repeater to device repeater by GPIO?

You cannot use I2C or GPIO to configure the repeater as a peripheral or a host. This configuration should take place over the eUSB2 lines (eDP/eDM) via the repeater communicating with the eUSB2 device. 

I2C and GPIO mode are used to configure the EQ of the PHY, as well as other signal conditioning aspects. It cannot force the orientation of the repeater.

Thanks,

Ryan

Hello Ryan,

Thanks a lot.

Ryan Kitto said:

You cannot use I2C or GPIO to configure the repeater as a peripheral or a host. This configuration should take place over the eUSB2 lines (eDP/eDM) via the repeater communicating with the eUSB2 device. 

According to TUSB2E221 datasheet, it seems CONFIG_PORT0/CONFIG_PORT1 register could configure the port as a Host repeater or a Device repeater.
Do you mean this register cannot be accessed via I2C? 

Ryan Kitto said:

After reviewing the eUSB2 spec, it does look like CM is needed for specifically FS operation. Section 5.4.4 details this:

I just read this page, but it seems CM is not necessary.
Could you elaborate more about why CM is needed?
1. In Figure 5-14, CM is only used to enter Lx, and SOWake could also be used to enter Lx.
2. Section 5.4.4.1 mentioned the repeater (eDSPp) shall ready to "detect" input activities such as a data packet, a CM,.., but it does not mention the repeater will send CM to device. 

Hi Andrew,

Andrew Chien said:

According to TUSB2E221 datasheet, it seems CONFIG_PORT0/CONFIG_PORT1 register could configure the port as a Host repeater or a Device repeater.
Do you mean this register cannot be accessed via I2C? 

This register can read how the repeater is currently configured, however it cannot configure the repeater itself. The type column indicates whether a register is read or write accessible, for this bit, it is only read accessible.

Andrew Chien said:

Could you elaborate more about why CM is needed?
1. In Figure 5-14, CM is only used to enter Lx, and SOWake could also be used to enter Lx.
2. Section 5.4.4.1 mentioned the repeater (eDSPp) shall ready to "detect" input activities such as a data packet, a CM,.., but it does not mention the repeater will send CM to device. 

CM is required to put the redriver into an L1 or L2 state, which is suspend or sleep and is required per the eUSB2 spec:

Certain aspects of peripheral repeater mode signaling is determined by the CM used to set the state of the peripheral.

The spec does not list whether certain modes require or don't require CM, so I believe it is best to implement CM regardless.

Thanks,

Ryan

Hello Ryan,

Thanks a lot, I still have some questions.

Ryan Kitto said:

This register can read how the repeater is currently configured, however it cannot configure the repeater itself. The type column indicates whether a register is read or write accessible, for this bit, it is only read accessible.

Thanks for your reminding! I didn't notice the type column.

So, the repeater will write the Repeater Configuration result into this register.

I just checked eUSB2 specification section 5.5.2, CM does not used in the timing diagram.
So the eUSB device can configure the repeater into Device Repeater without using CM, is my understanding correct? 

Ryan Kitto said:

CM is required to put the redriver into an L1 or L2 state, which is suspend or sleep and is required per the eUSB2 spec:

eUSB2 spec mentioned "A repeater shall transition to L1 or L2 Suspend if CM.L1 or CM.L2 is received", but if the device does not send CM.L1 or CM.L2, will there be any violation to the specification?

Ryan Kitto said:

The spec does not list whether certain modes require or don't require CM, so I believe it is best to implement CM regardless.

Thanks for your suggestion.
But it needs more resource and time to implement CM in our product.

The situation is: our device is a peripheral on PC, which only supports USB FS.
Customer would like us to support eUSB, so we plan to modify the PHY design.
We checked with Intel whether CM is needed in native mode, the answer is "not needed".
However, in manufacture side, we'd like to use eUSB repeater to test our device.
Is it necessary to implement CM if the eUSB repeater is only used for test?

Hi Andrew,

Andrew Chien said:

I just checked eUSB2 specification section 5.5.2, CM does not used in the timing diagram.
So the eUSB device can configure the repeater into Device Repeater without using CM, is my understanding correct? 

It does not appear here I agree, however it is still my understanding that CM is needed to actually configure the repeater into peripheral mode, even though it is not listed here. It may be best to check with Intel or reach out to the USB-IF for firm confirmation, as we have always recommended customers use CM with our repeaters.

Andrew Chien said:

eUSB2 spec mentioned "A repeater shall transition to L1 or L2 Suspend if CM.L1 or CM.L2 is received", but if the device does not send CM.L1 or CM.L2, will there be any violation to the specification?

This would mean that the repeater would be stuck at in an L0 active state and actively consume more power than if it were placed into L1 or L2. 

Andrew Chien said:

Thanks for your suggestion.
But it needs more resource and time to implement CM in our product.

The situation is: our device is a peripheral on PC, which only supports USB FS.
Customer would like us to support eUSB, so we plan to modify the PHY design.
We checked with Intel whether CM is needed in native mode, the answer is "not needed".
However, in manufacture side, we'd like to use eUSB repeater to test our device.
Is it necessary to implement CM if the eUSB repeater is only used for test?

Correct, for a native application (eUSB Host to eUSB Peripheral), CM is not needed. However, for a repeater application (USB2 host to eUSB2 peripheral in this case), CM functionality is needed to ensure the eUSB peripheral is fully functional, including entering suspend states. Without CM's, it is not possible for the repeater to enter a suspend state for full testing.

How exactly does your customer expect you to support eUSB? Do they just want to have a device that supports eUSB2 signaling for lower power? If power is a concern, then not having CM will at the very least mean the repeater will always be consuming more power than needed when in an idle state.

Thanks,

Ryan

Ryan Kitto said:

It does not appear here I agree, however it is still my understanding that CM is needed to actually configure the repeater into peripheral mode, even though it is not listed here.

Do you mean CM is needed for TUSB2E221 to configure the repeater into peripheral mode?
Could you help measure the signals by Logic analyzer or protocol analyzer to make sure whether it is used?

Ryan Kitto said:

This would mean that the repeater would be stuck at in an L0 active state and actively consume more power than if it were placed into L1 or L2.

We just use TUSB2E221 to make the eUSB portion on our device is workable, so the power consumption is acceptable.

Ryan Kitto said:

How exactly does your customer expect you to support eUSB? Do they just want to have a device that supports eUSB2 signaling for lower power? If power is a concern, then not having CM will at the very least mean the repeater will always be consuming more power than needed when in an idle state.

If Intel CPU is used, we will use native mode.
But the customer may also use AMD CPU, and connect to eUSB devices via repeater;
In this condition, the repeater will not enter Lx, and the power consumption is around 108mW, is my understanding correct?

Hi Andrew,

Andrew Chien said:

Do you mean CM is needed for TUSB2E221 to configure the repeater into peripheral mode?
Could you help measure the signals by Logic analyzer or protocol analyzer to make sure whether it is used?

Unfortunately, we do not have a logic/protocol analyzer that supports eUSB2 protocol messaging, and most logic/protocol analyzers still do not have the ability to capture these messages.

Will there be any HS functionality, or purely FS with no HS connection? 

The top of section 3.3 indicates that control messages are used between two ports with single-ended signaling (LS/FS). They are used for starting reset, L1/L2, and register access/RAP.

I talked internally with our team to discuss feasibility, and going by the spec it's true that it seems like CM are not required for a minimum of FS communication at FS only. However, this is not something our team has every tested, so we cannot guarantee whether all the functionality you need for your application will be there or not. Like previously pointed out, you'll lose reset and L1/L2 functionality.

The primary requirement is that your eUSB2 peripheral is able to configure the repeater as a peripheral, so as long as it can do that, then the repeater should be able to work functionally. I would recommend using an EVM to confirm that this is the case.

What exactly is this application? Is cost the primary concern for implementing CM or a standard eUSB2 PHY?

Andrew Chien said:

If Intel CPU is used, we will use native mode.
But the customer may also use AMD CPU, and connect to eUSB devices via repeater;
In this condition, the repeater will not enter Lx, and the power consumption is around 108mW, is my understanding correct?

For a FS-only application, the power usage would be lower than 108mW, as that's for a HS application:

Thanks,

Ryan

Hello Ryan,

Thanks a lot for your support.

Ryan Kitto said:

Will there be any HS functionality, or purely FS with no HS connection?

It will be purely FS connection.

Ryan Kitto said:

The top of section 3.3 indicates that control messages are used between two ports with single-ended signaling (LS/FS). They are used for starting reset, L1/L2, and register access/RAP

According to the timing diagram of FS Link Bus Reset, only host side eUSB2 need CM.Reset.
Does TUSB2E221 use CM.Reset for peripheral side eUSB2?

L1/L2 is not necessary for our function test.

Ryan Kitto said:

The primary requirement is that your eUSB2 peripheral is able to configure the repeater as a peripheral,

The requirement is described in eUSB2 specification section 5.5.2, is my understanding correct?

Ryan Kitto said:

I would recommend using an EVM to confirm that this is the case.

We have ordered TUSB2E221QFNEVM from the distributor (Mouser). But we don't have any eUSB device now.
Could we connect TUSB2E221's eUSB2 Port0 to Port1, and measure the eUSB2 signal?

Ryan Kitto said:

Is cost the primary concern for implementing CM or a standard eUSB2 PHY?

The main concern is the schedule;
The original plan is changing PHY in a very short time. implementing CM need more time and could keep catch customer schedule. 

Hi Andrew,

Andrew Chien said:

According to the timing diagram of FS Link Bus Reset, only host side eUSB2 need CM.Reset.
Does TUSB2E221 use CM.Reset for peripheral side eUSB2?

Looking at the spec, it looks like CM.Reset is not used on the peripheral side is. CM.FS is used during a HS connection so if there is no HS connection, I would not expect that command to be used.

Andrew Chien said:

The requirement is described in eUSB2 specification section 5.5.2, is my understanding correct?

Correct, the peripheral you are developing must be able to at least support this process.

Andrew Chien said:

We have ordered TUSB2E221QFNEVM from the distributor (Mouser). But we don't have any eUSB device now.
Could we connect TUSB2E221's eUSB2 Port0 to Port1, and measure the eUSB2 signal?

You want to test the eUSB functionality by connecting eUSB port 0 to eUSB port 1? This will not work, as an eUSB host or eUSB peripheral is needed to configure the repeater, connecting these ports together will not do anything.

Andrew Chien said:

The main concern is the schedule;
The original plan is changing PHY in a very short time. implementing CM need more time and could keep catch customer schedule. 

I understand. Again, I would caution against not implementing a full PHY in this case, as that is the expected and compliant use case for our repeater, but if that is not possible then I understand.

Thanks,

Ryan

Ryan Kitto said:

Correct, the peripheral you are developing must be able to at least support this process.

Thanks a lot.
We are checking whether our peripheral device can support section 5.5.2 process.
But we don't know how will the peripheral device distinguish native connection (section 4.3.3.1) and repeater configuration (section 5.5.2).
When the peripheral eUSB2 device is connected to a repeater, how does the peripheral know the that it not a native host and start repeater configuration?
I guess the peripheral may wait for the Port Reset from native host for a predefined time, after that time, it will start repeater configuration.
But the time is not described in the specification.

Could you elaborate more about it? Thanks a lot.

Hi Andrew,

Andrew Chien said:

But we don't know how will the peripheral device distinguish native connection (section 4.3.3.1) and repeater configuration (section 5.5.2).
When the peripheral eUSB2 device is connected to a repeater, how does the peripheral know the that it not a native host and start repeater configuration?

I believe this is primarily determined by timing on the eUSB lanes. Section 4.3.3.1 and section 5.5.2 have timeline markings in their figures to show when a certain signal is transmitted and by what. In section 5.5.2, it looks like eUSPr transmits Port Reset to the peripheral, while in a native configuration, eDSPn would transmit Port Reset.

The primary difference is likely in the timing, where after a certain time in where the peripheral does not detect a Port Reset from a host, which leads it to instead transmit it's own Port Reset to try and perform repeater configuration. In the figures for both these sections, you can see a difference in the timing of the native configuration versus the repeater configuration. This same process also occurs for host mode repeater configuration.

Thanks,

Ryan

Hi Ryan,

Thanks a lot.

Ryan Kitto said:

In section 5.5.2, it looks like eUSPr transmits Port Reset to the peripheral,

Is there a typo? In section 5.5.2, eUSPr transmits Port Reset to the repeater (eDSPp), not the peripheral.

Ryan Kitto said:

The primary difference is likely in the timing, where after a certain time in where the peripheral does not detect a Port Reset from a host, which leads it to instead transmit it's own Port Reset

We also think so, but we don't know how long the peripheral should wait before transmitting its own Port Reset.
Do you know where can we find the information?

Hi Andrew,

Andrew Chien said:

Is there a typo? In section 5.5.2, eUSPr transmits Port Reset to the repeater (eDSPp), not the peripheral.

Sorry, yes eUSBr transmits to eDSPp on the repeater, transmitting Port Reset to the peripheral would just be a loop

Andrew Chien said:

We also think so, but we don't know how long the peripheral should wait before transmitting its own Port Reset.
Do you know where can we find the information?

I am looking for it in the spec but I'm not totally sure either. I would recommend reaching out to the USB-IF to see if they can answer it exactly using the email listed in the spec: techsup@usb.org  

Thanks,
Ryan