Electronics > FPGA
Using ULPI USB PHYs for custom data links
SiliconWizard:
I've read about this on a couple of forums, but without much details.
Has any of you implemented (or at least considered) custom data links using an USB PHY (so, with a custom protocol, and not USB)? That would give you the PHY for pretty cheap (you can find USB 2.0 PHYs, so a 480Mb/s link, for less than $2 or so). Good for cables up to 5m according to the standard, but I'm pretty sure one can achieve longer than this with off-the-shelf PHYs using custom cables and protocols, and not transporting power.
The reason for considering USB PHYs is flexibility, data rate and cost. While those are cheap (for market reasons), gigabit Ethernet PHYs tend to be more expensive (but don't hesitate to point me to "cheap" ones), and dedicated "SERDES" ICs with integrated CDR tend to be VERY expensive. (Like easily $20 to $40 per 1.)
Is ULPI flexible enough to allow this? (I've just started studying it so I'll still have to figure this out.)
I posted that in the FPGA section, but of course that could also be used with MCUs.
Speaking of FPGAs, the higher-end ones usually embed SERDES blocks, some with clock/data recovery and everything, so that implementing ustom "high-speed" data links is relatively straightforward, but for lower-end ones, there's no such thing, and so you're pretty limited in the max data rate you can reasonably achieve (and having to implement CDR yourself using oversampling and such...)
Any thoughts welcome.
asmi:
--- Quote from: SiliconWizard on April 28, 2022, 05:44:34 pm ---I've read about this on a couple of forums, but without much details.
Has any of you implemented (or at least considered) custom data links using an USB PHY (so, with a custom protocol, and not USB)? That would give you the PHY for pretty cheap (you can find USB 2.0 PHYs, so a 480Mb/s link, for less than $2 or so). Good for cables up to 5m according to the standard, but I'm pretty sure one can achieve longer than this with off-the-shelf PHYs using custom cables and protocols, and not transporting power.
The reason for considering USB PHYs is flexibility, data rate and cost. While those are cheap (for market reasons), gigabit Ethernet PHYs tend to be more expensive (but don't hesitate to point me to "cheap" ones), and dedicated "SERDES" ICs with integrated CDR tend to be VERY expensive. (Like easily $20 to $40 per 1.)
--- End quote ---
You can use RS485/422 transceivers, they are relatively cheap (unless you want galvanic isolation), and some can hit some fairly impressive speeds (up to 50 Mbit/s over a distance of a few meters).
--- Quote from: SiliconWizard on April 28, 2022, 05:44:34 pm ---Is ULPI flexible enough to allow this? (I've just started studying it so I'll still have to figure this out.)
--- End quote ---
Why not? It could be possible, since most PHYs only concepn themselves with well PHYsical coding and access. You might want to read the ULPI spec and experiment a bit. I suspect that you will still need to follow an initial handshake protocol because it's required for syncronization, but once "connection" is established, it should work.
I would be wary of using such a hodge-podge solution in any real commercial project, but if it's "for science" - why not give it a try and see what happens?
--- Quote from: SiliconWizard on April 28, 2022, 05:44:34 pm ---Speaking of FPGAs, the higher-end ones usually embed SERDES blocks, some with clock/data recovery and everything, so that implementing ustom "high-speed" data links is relatively straightforward, but for lower-end ones, there's no such thing, and so you're pretty limited in the max data rate you can reasonably achieve (and having to implement CDR yourself using oversampling and such...)
Any thoughts welcome.
--- End quote ---
In Xilinx world (at least 7 series and above), the minimum official supported line speed for MGT is 500 Mbit/s, but they also provide ready-to-use HDL for any SERDES-based solution (and a SERDES module is embedded into every single IO tile in all Xilinx devices) for speeds up to 1.25 Gbit/s, and these SERDES modules have a special mode when it consists of essentially four strings of flip-flops (3 in each) allowing you to implement a 4x oversampling with minimal effort. For even lower speeds, you can basically just run the IO part of it at a multiple of a line frequency and implement a multisampling manually.
SiliconWizard:
I've used LVDS transceivers for links up to 50 Mbps or so, and this is rather straightforward.
But we're talking about an order of magnitude faster with the idea of using USB PHYs in HS mode.
I know this is doable with SERDES, but as I said, some FPGAs do not even have true SERDES, and even when they do,while the TX part is straightforward, the RX part, not necessarily so for recovering the clock. Some FPGAs do have proper CDR, with some other, you need to hand-implement them. This is not trivial to implement robust CDR. I'm sure some vendors provide ready-to-use IPs for this. I'll have to see for the Artix-7, but otherwise, you often have to go for higher-end devices. I've read a couple papers about CDRs too, and implementing this on FPGAs with no CDR and just by oversampling, it seems hard to reach beyond something like 200-300Mbps reliably, and it's not even trivial...
To make things clear, I'm talking about transmission over a single pair, requiring clock recovery on the RX end.
So. After having read the ULPI spec, I actually think using USB 2.0 PHYs should be absolutely doable. The "only" constraint you'd have is that the transmission of data would have to occur in data packets as defined by the USB standard - that's basically a sync preamble, packet ID, data payload, CRC and end of packet. Since there's a sync preamble at the beginning of each packet, there is nothing else to do for clock synchronization actually, if I understood it right. All the rest is for the USB protocol (like speed "negotiation", tokens, etc).
This is for experimenting at the moment, but why would it not be usable for a commercial solution? As long as one follows the ULPI spec, and the physical part of the USB spec, I can't really see a potential problem. Now as I mentioned, benefits are that we get a relatively robust PHY solution able to drive cables of several meters, for basically the cost of an LVDS or RS485 transceiver. But any reasonable counter-argument is welcome.
asmi:
--- Quote from: SiliconWizard on April 29, 2022, 08:39:02 pm ---I've used LVDS transceivers for links up to 50 Mbps or so, and this is rather straightforward.
But we're talking about an order of magnitude faster with the idea of using USB PHYs in HS mode.
--- End quote ---
You never said what kind of speed you're looking for, so I tried to cover the whole spectrum. For lower speeds and long transmission lines, RS485/422 is definetly the best choice as it's the most reliable channel.
--- Quote from: SiliconWizard on April 29, 2022, 08:39:02 pm ---I know this is doable with SERDES, but as I said, some FPGAs do not even have true SERDES, and even when they do,while the TX part is straightforward, the RX part, not necessarily so for recovering the clock. Some FPGAs do have proper CDR, with some other, you need to hand-implement them. This is not trivial to implement robust CDR. I'm sure some vendors provide ready-to-use IPs for this. I'll have to see for the Artix-7, but otherwise, you often have to go for higher-end devices. I've read a couple papers about CDRs too, and implementing this on FPGAs with no CDR and just by oversampling, it seems hard to reach beyond something like 200-300Mbps reliably, and it's not even trivial...
--- End quote ---
Xilinx provides an appnote with ready-to-use HDL for implementing 4x oversampling up to 1.25 Gpbs, so it's completely trivial. You just need any 7 series FPGA with speed grade of 2 or higher (or you are willing to overclock the SG1 device).
--- Quote from: SiliconWizard on April 29, 2022, 08:39:02 pm ---So. After having read the ULPI spec, I actually think using USB 2.0 PHYs should be absolutely doable. The "only" constraint you'd have is that the transmission of data would have to occur in data packets as defined by the USB standard - that's basically a sync preamble, packet ID, data payload, CRC and end of packet. Since there's a sync preamble at the beginning of each packet, there is nothing else to do for clock synchronization actually, if I understood it right. All the rest is for the USB protocol (like speed "negotiation", tokens, etc).
--- End quote ---
Well give it a try and let us know how it went.
--- Quote from: SiliconWizard on April 29, 2022, 08:39:02 pm ---This is for experimenting at the moment, but why would it not be usable for a commercial solution? As long as one follows the ULPI spec, and the physical part of the USB spec, I can't really see a potential problem. Now as I mentioned, benefits are that we get a relatively robust PHY solution able to drive cables of several meters, for basically the cost of an LVDS or RS485 transceiver. But any reasonable counter-argument is welcome.
--- End quote ---
Just a few reasons I can think of off top of my head:
1. Users are stupid. What will happen to both sides if you connect your device to a PC? What about connecting some random peripheral? What if they accidentally use a power-only USB cable?
2. USB was not designed for high-EMI environments, and most USB 2 cables I've come across are not properly shielded.
3. Since USB is half-duplex, you only get half of the claimed bandwidth if you need to send data in both directions.
4. Using MGT is much easier as it requires no external components (aside from AC-coupling caps), and there are fairly low-end FPGAs which have them, and pretty fast too (up to 6.6 Gpbs for Artix in some packages).
5. This one is personal - I live by KISS principle, and hate all of this smart-assery, which tends to bite you in the back when you least expect it, so I do my best to avoid off-label uses. Few bucks saved on parts often end up costing tens of thousands $$$ more for extra development, testing and validation - I've seen this far too many times to be willing to repeat it.
langwadt:
--- Quote from: asmi on April 29, 2022, 09:11:23 pm ---
--- Quote from: SiliconWizard on April 29, 2022, 08:39:02 pm ---I've used LVDS transceivers for links up to 50 Mbps or so, and this is rather straightforward.
But we're talking about an order of magnitude faster with the idea of using USB PHYs in HS mode.
--- End quote ---
You never said what kind of speed you're looking for, so I tried to cover the whole spectrum. For lower speeds and long transmission lines, RS485/422 is definetly the best choice as it's the most reliable channel.
--- Quote from: SiliconWizard on April 29, 2022, 08:39:02 pm ---I know this is doable with SERDES, but as I said, some FPGAs do not even have true SERDES, and even when they do,while the TX part is straightforward, the RX part, not necessarily so for recovering the clock. Some FPGAs do have proper CDR, with some other, you need to hand-implement them. This is not trivial to implement robust CDR. I'm sure some vendors provide ready-to-use IPs for this. I'll have to see for the Artix-7, but otherwise, you often have to go for higher-end devices. I've read a couple papers about CDRs too, and implementing this on FPGAs with no CDR and just by oversampling, it seems hard to reach beyond something like 200-300Mbps reliably, and it's not even trivial...
--- End quote ---
Xilinx provides an appnote with ready-to-use HDL for implementing 4x oversampling up to 1.25 Gpbs, so it's completely trivial. You just need any 7 series FPGA with speed grade of 2 or higher (or you are willing to overclock the SG1 device).
--- Quote from: SiliconWizard on April 29, 2022, 08:39:02 pm ---So. After having read the ULPI spec, I actually think using USB 2.0 PHYs should be absolutely doable. The "only" constraint you'd have is that the transmission of data would have to occur in data packets as defined by the USB standard - that's basically a sync preamble, packet ID, data payload, CRC and end of packet. Since there's a sync preamble at the beginning of each packet, there is nothing else to do for clock synchronization actually, if I understood it right. All the rest is for the USB protocol (like speed "negotiation", tokens, etc).
--- End quote ---
Well give it a try and let us know how it went.
--- Quote from: SiliconWizard on April 29, 2022, 08:39:02 pm ---This is for experimenting at the moment, but why would it not be usable for a commercial solution? As long as one follows the ULPI spec, and the physical part of the USB spec, I can't really see a potential problem. Now as I mentioned, benefits are that we get a relatively robust PHY solution able to drive cables of several meters, for basically the cost of an LVDS or RS485 transceiver. But any reasonable counter-argument is welcome.
--- End quote ---
Just a few reasons I can think of off top of my head:
1. Users are stupid. What will happen to both sides if you connect your device to a PC? What about connecting some random peripheral? What if they accidentally use a power-only USB cable?
2. USB was not designed for high-EMI environments, and most USB 2 cables I've come across are not properly shielded.
3. Since USB is half-duplex, you only get half of the claimed bandwidth if you need to send data in both directions.
4. Using MGT is much easier as it requires no external components (aside from AC-coupling caps), and there are fairly low-end FPGAs which have them, and pretty fast too (up to 6.6 Gpbs for Artix in some packages).
5. This one is personal - I live by KISS principle, and hate all of this smart-assery, which tends to bite you in the back when you least expect it, so I do my best to avoid off-label uses. Few bucks saved on parts often end up costing tens of thousands $$$ more for extra development, testing and validation - I've seen this far too many times to be willing to repeat it.
--- End quote ---
noone says you need to use USB cables and connectors, and MGT is going to need cables and connectors too
Navigation
[0] Message Index
[#] Next page
Go to full version