I am developing USB interface with XS1-L16. According to the datasheet, pins should be assigned:
* D12, D13, D22, D23: ULPI_STP, ULPI_NXT, ULPI_DIR, ULPI_CLK
* D14---D21: ULPI_DATA[0...7]
* D2----D9: reserved ( as PORT_USB_TXD)
(D26----D33, D37--D43 also reserved)
Can I change pin assignment (easy PCB routing for me), so that I can still use XMOS USB library?
*D14---D21: reserved ( as PORT_USB_TXD)
* D2----D9: ULPI_DATA[0...7]
[/highlight]
Thanks!
Pin re-assignment for XMOS USB interface?
-
- Experienced Member
- Posts: 65
- Joined: Tue Apr 30, 2013 10:41 pm
Unfortunately, ULPI pin configuration cannot be changed.
-
- Experienced Member
- Posts: 65
- Joined: Tue Apr 30, 2013 10:41 pm
I understand what you mean.
But are you XMOS insider? Can you read carefully about my new pin assignment, and double confirm your answer?
(I just change the pin assignments for ULPI_DATA[0..7], does it really matter?)
Thanks!
But are you XMOS insider? Can you read carefully about my new pin assignment, and double confirm your answer?
(I just change the pin assignments for ULPI_DATA[0..7], does it really matter?)
Thanks!
-
- XCore Expert
- Posts: 754
- Joined: Thu Dec 10, 2009 6:56 pm
ULPI is hardware assisted on XS1-L, so you cannot diverge from the assignments as stated in the datasheet.
-
- Experienced Member
- Posts: 65
- Joined: Tue Apr 30, 2013 10:41 pm
I understand that it is "hardware assisted", but let's see the XUD library("xud.h"):
#define PORT_USB_TXD on USB_TILE: XS1_PORT_8A
#define PORT_USB_RXD on USB_TILE: XS1_PORT_8B
So, with my new pin-assignments, I just exchange the assignments:
#define PORT_USB_TXD on USB_TILE: XS1_PORT_8B
#define PORT_USB_RXD on USB_TILE: XS1_PORT_8A
So how does my assignment affect the XUD library function?
should not it still work?
#define PORT_USB_TXD on USB_TILE: XS1_PORT_8A
#define PORT_USB_RXD on USB_TILE: XS1_PORT_8B
So, with my new pin-assignments, I just exchange the assignments:
#define PORT_USB_TXD on USB_TILE: XS1_PORT_8B
#define PORT_USB_RXD on USB_TILE: XS1_PORT_8A
So how does my assignment affect the XUD library function?
should not it still work?
-
- New User
- Posts: 3
- Joined: Tue May 19, 2015 8:46 pm
What does it mean that XS1-L has "hardware assisted" USB? There is no documentation whatsoever for any USB-specific hardware assistance module in the L devices. Do you have any official sources for such?Bianco wrote:ULPI is hardware assisted on XS1-L, so you cannot diverge from the assignments as stated in the datasheet.
After spending a couple of hours looking at the XUD source code, I was under an impression that the ports were used merely as an implementation detail - to leverage the port hardware in a rather unorthodox way. In such case, the ports should be freely reassignable. Basically, XUD seems to use 6 extra ports on top of the 5 ports used for ULPI (1 for data, 4 for control signals).
XUD has other nice undocumented tidbits, such as granular port delay settings...
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Taking a logical stab at this that the specified pins for the USB PHY are proven to be operational with the supplied code. Respectively, the developers are hinting at some potential coding grief which you may face down the road if the USB PHY ports are tasked to other locations. Otherwise, cannot see a reason why the pins could not be re-assigned to suit your project since in the end, the USB PHY is "just" another digital interface. As noted, the specified pins for the project have some proven history with the locked in software support.
Curious to know if you have reviewed the use of the XS1-U16A-128-FB217 which features an internal USB PHY. Granted not the same number of IO as the XS1-L16A but then again, you no longer have to stitch an external USB PHY. Would that not be a cleaner solution also for your PCB layout ?
How many PCB layers are you planning to use for this project ? We would recommend as a minimum, 4 layers (FR4). Do apply a good quality USB 2.0 compliant ESD TVS protection device onto the USB connector / interface.
Do you have access to USB bus analyzer tools ?
Updating my own post :)
The XS1-L16A appears to be automotive grade (ie. support for higher temps @ -40C..105 C - nice !!)
The XS1-U16A is available in commercial temp (0..70 C) and also industrial (-40C..85 C) temp (but not automotive grade / temp)
interesting to learn this. Is the operating temp a factor to your component decision ?
Curious to know if you have reviewed the use of the XS1-U16A-128-FB217 which features an internal USB PHY. Granted not the same number of IO as the XS1-L16A but then again, you no longer have to stitch an external USB PHY. Would that not be a cleaner solution also for your PCB layout ?
How many PCB layers are you planning to use for this project ? We would recommend as a minimum, 4 layers (FR4). Do apply a good quality USB 2.0 compliant ESD TVS protection device onto the USB connector / interface.
Do you have access to USB bus analyzer tools ?
Updating my own post :)
The XS1-L16A appears to be automotive grade (ie. support for higher temps @ -40C..105 C - nice !!)
The XS1-U16A is available in commercial temp (0..70 C) and also industrial (-40C..85 C) temp (but not automotive grade / temp)
interesting to learn this. Is the operating temp a factor to your component decision ?
-
- New User
- Posts: 3
- Joined: Tue May 19, 2015 8:46 pm
It appears that there is a hidden hardware assist module, called UIFM, that lives even in L series devices. libxud appears to use this hidden hardware - upon some further examination, it seems that it doesn't speak ULPI directly. If it did speak ULPI, it really wouldn't need the extra ports for anything. I was initially under the impression that the ports were used for their events only, but that's not the case and I was wrong about that.mon2 wrote:Taking a logical stab at this that the specified pins for the USB PHY are proven to be operational with the supplied code. Respectively, the developers are hinting at some potential coding grief which you may face down the road if the USB PHY ports are tasked to other locations. Otherwise, cannot see a reason why the pins could not be re-assigned to suit your project since in the end, the USB PHY is "just" another digital interface. As noted, the specified pins for the project have some proven history with the locked in software support.
The existence of UIFM is not such a surprise, since XMOS took the approach of not providing comprehensive product documentation. When you use OMAP from TI, you get a nice 3,500 page document that tells you everything there's to be known about what's on the chip. XMOS thinks that their users don't need any of this. Frankly said, the only reason that we use XS-1 is that there's no other fixed-function silicon that does what we need. The documentation itself would be grounds to disqualify it, but other providers of similar silicon seem to be even worse. As it is, XS-1 gives us the competitive advantage we need, so reluctantly, we can't but use it. I'm doing quite a bit of reverse-engineering to figure things out, though.
We have multiple ethernet PHYs already, and two L16A's connected over two links, so the USB PHY is not a big deal. Currently we run a USB2 FS master, but a HS master is not out of the question as the timings all work out. With some head-scratching a "native" ULPI HS device might work, but that requires some serious pushing of the architecture, and the use of two overlapping ports.mon2 wrote:Curious to know if you have reviewed the use of the XS1-U16A-128-FB217 which features an internal USB PHY. Granted not the same number of IO as the XS1-L16A but then again, you no longer have to stitch an external USB PHY. Would that not be a cleaner solution also for your PCB layout ?
We use six, with two full coverage power planes that the return currents get a good ride on.How many PCB layers are you planning to use for this project ? We would recommend as a minimum, 4 layers (FR4).
The PHY supplies sufficient ESD protection. We have a bus analyzer too.Do apply a good quality USB 2.0 compliant ESD TVS protection device onto the USB connector / interface. Do you have access to USB bus analyzer tools ?
Very much so.Is the operating temp a factor to your component decision ?
-
- XCore Expert
- Posts: 968
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
Have you considered using xCORE-200? You would get some I/O back.
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Be sure to review this thread on topic of datasheet errors related to the XS1-L device:
http://www.xcore.com/questions/2833/xs1 ... cu-problem
The issues were due to the PCU pin connections on this component. The current datasheet appears to have been revised and corrected so best to review the posted checklist inside that document.
Summarized here:
http://www.xcore.com/questions/2833/xs1 ... cu-problem
The issues were due to the PCU pin connections on this component. The current datasheet appears to have been revised and corrected so best to review the posted checklist inside that document.
Summarized here:
- The PCU_VDD pin is connected to the VDD supply and PCU_VDDIO is
connected to the VDDIO supply (Section 10).
- The PCU_CLK pin is supplied with a clock, for example it is tied to the
main CLK (Section 9.1).
- The PCU_VDD supply must be connected to the VDD supply.
- The PCU_VDDIO supply must be connected to the VDDIO supply.
- The PCU_WAKE and PCU_GATE pins should be left unconnected (Section
9.1).