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.)
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.
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...
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.
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.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.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...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).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).Well give it a try and let us know how it went.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.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.
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.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.
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...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).
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).Well give it a try and let us know how it went.
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.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.
As to FPGA-based solutions, I suppose asmi was referring to the XAPP523 app note from Xilinx. I'm reading it. Looks like pretty textbook oversampling stuff. It's not overly problematic to implement this in a generic way if you don't want Xilinx-specific stuff, the only issue is having true SERDES blocks in order to reach a decent rate. I'm currently using ECP5, for instance, and the bare version doesnt have true SERDES. The version with SERDES requires licensing for Diamond. Also, most of their more advanced IPs are paid ones, so you're stuck implementing this by hand. Not that this is overly complicated, but the devil's always in the details. Even the non-SERDES version of ECP5 might be ok for something around 400-500Mbps, but that might not be easy. Something to investigate.
Also, as I mentioned, the more high-end FPGAs often embed true CDR blocks, so there's no need to fiddle with oversampling, and the result is more robust and more flexible.
Regarding "no external components", what do you guys think? As I said, I don't much like directly routing FPGA IOs to connectors. Typical USB PHYs embed various means of protection. Sure you can always add discrete protection.
A side note for this idea is that the question of implementing some "high-speed" link between a MCU and a FPGA often pops up. Above a few tens of Mb/s, using SPI, you're often stuck. Or you'll have to resort to some parallel bus / memory interface, requiring many IOs and having all sorts of limitations depending on the MCU itself. While, if using a MCU with embedded USB HS, it's likely possibly to implement such a link using the same idea: using the embedded USB core with a custom protocol, which would save having to implement full-blown USB when this would be largely overkill - knowing that USB cores in MCUs are often pretty similar to external USB PHYs in terms of functionalities, the bulk of the USB protocol being implemented in software.
Is ULPI flexible enough to allow this? (I've just started studying it so I'll still have to figure this out.)
Is ULPI flexible enough to allow this? (I've just started studying it so I'll still have to figure this out.)The ULPI is a standard connection channel specification to your FPGA. A ULPI PHY IC is a USB cable driver with a simple ser & deser, clock recovery circuitry in it and simple USB arbitration, so your FPGA interface only runs at 1/2 or 1/4 480mb speed (3 pin VS 6 pin mode). Meaning you do not need a 480megabit ser-des in your FPGA. These ULPI PHY ICs are stupid other than a ser-des plus USB status. Everything else you need to program in the FPGA, but with the knowledge you are receiving and transmitting your packet structures and contents in bytes.
You should have access to 100% of the USB2.x capabilities with a ULPI PHY IC.
Even the GTP that the Artix (and I think Spartan 7?) have seem to have some kind of CDR, but as far as I can tell, it's not a full CDR as I think of it: they can't recover clock and data on their own (unless I missed something, I'm not an expert with the Xilinx 7-series), which is why the app note mentioned earlier shows a way to recover data (not the clock) using oversampling. That's not any kind of hardware CDR as I call it. But, as far as I've seen, the Virtex seem to have that. Now whether you'd get better, or at least as good performance (data integrity) relative to jitter and clock drift for a ~500Mbps link than a dedicated USB PHY, I do not know. But having read some papers about clock/data recovery and oversampling, I'm not completely sure that is the case with 4x oversampling and a relatively simple scheme. Maybe it is though. I'd be curious to see eye patterns and compare them - problem being that you can't directly get an eye pattern with the oversampling method, as you don't recover the clock.
The ECP5 without SERDES (again, as *Lattice* calls it, which would be the equivalent of MGT), from what I've read, is limited to 400 MHz on its IOs. So that's a bit rough. But you wouldn't get better with many other FPGAs of this "range", or even lower end. For those, alternatives can be nice to have.
800MBPS for -8, 700MBPS for -7, 624MBPS on the -6 when running it's SER-DES in DDRX2 mode, 500MBPS in DDRX1 mode for all speed grades.
Remember, a 400MHz toggle rate means a 800mbps ser-des capability. If not, it would be impossible to use DDR3 ram with these FPGAs which requires a minimum 606mbps ser-des.
Page 66, 67 and 68, Table 3.22. ECP5/ECP5-5G External Switching Characteristics in the ECP5 and ECP5-5G Family data sheet. Read the 'data rates' column.
The ECP5 without SERDES (again, as *Lattice* calls it, which would be the equivalent of MGT), from what I've read, is limited to 400 MHz on its IOs. So that's a bit rough. But you wouldn't get better with many other FPGAs of this "range", or even lower end. For those, alternatives can be nice to have.800MBPS for -8, 700MBPS for -7, 624MBPS on the -6 when running it's SER-DES in DDRX2 mode, 500MBPS in DDRX1 mode for all speed grades.
Remember, a 400MHz toggle rate means a 800mbps ser-des capability. If not, it would be impossible to use DDR3 ram with these FPGAs which requires a minimum 606mbps ser-des.
Page 66, 67 and 68, Table 3.22. ECP5/ECP5-5G External Switching Characteristics in the ECP5 and ECP5-5G Family data sheet. Read the 'data rates' column.
800MBPS for -8, 700MBPS for -7, 624MBPS on the -6 when running it's SER-DES in DDRX2 mode, 500MBPS in DDRX1 mode for all speed grades.
Remember, a 400MHz toggle rate means a 800mbps ser-des capability. If not, it would be impossible to use DDR3 ram with these FPGAs which requires a minimum 606mbps ser-des.
Page 66, 67 and 68, Table 3.22. ECP5/ECP5-5G External Switching Characteristics in the ECP5 and ECP5-5G Family data sheet. Read the 'data rates' column.That's still rather pathetic compared to 7 series which can do 950 Mbps in the slowest speed grade (1), and 1.25 Gbps for any other speed grades. And that for any differential pair pins, of which there are 24 pairs per I/O bank - so 48 out of 50 I/O in the bank are capable of reaching max wire speed.
As to availability, well, even the ECP5 that was available a few months back when others weren't, it's now become pretty much unobtainium as well...
This is not an X/Y problem. I know what the alternative is if you use FPGAs with fast enough IOs or dedicated transceivers. So the idea is for when you can't use that, while using a standard solution (even if it means using a subset of it), allowing for *portability* of the approach. And portability is a pretty nice thing to have these days due to gigantic problems of availability. I was curious about whether others had already thought about it, or done it. So, the thread was mostly about that. And, if that can give ideas to some people, great. If not, that's fine too.
As to availability, well, even the ECP5 that was available a few months back when others weren't, it's now become pretty much unobtainium as well...
https://www.verical.com/pd/lattice-semiconductor-fpga-lfe5u-25f-6bg256c-5869565
25kgates at 8$.
Though 17924 in stock, it ships from Hong Kong.
Digikey has 80 of the the top end ones with the high speed transceivers:
https://www.digikey.com/en/products/detail/lattice-semiconductor-corporation/LFE5UM5G-85F-8BG381I/6173749?s=N4IgjCBcoLQCxVAYygMwIYBsDOBTANCAPZQDaIcArABxgCcIhlcA7AAxsgC6AvoTACZEIFJAAuAJwCuBYmRCVuPPiCGRymdGLEBLJLgAEqAA4BzdN0IA2YToAmUEDDBsIhY2MeMQYgJ7HcR3RsFGUgA
And at 18$/36$ respectively, you can get the same FPGA with a number of 3.25gbit serdes ports.
Thanks for the first link, I'll have a look. I didn't know about them.
As to Digikey, I looked a couple days ago and could find any in stock I think. The one you linked to has 74 in stock and probably zero pretty soon...