Using ULPI USB PHYs for custom data links

[SpacedCowboy]

If you're open to repurposing different protocols, Efinix have $10 parts with hardened MIPI CSI2 - 4 data lanes @ 1.5gbps each + a clock lane. Each device has 2 RX and 2 TX hard cores on it. You don't get access directly to the transceivers, unfortunately, so you'd actually have to packet stuff up in a way that made sense to the MIPI interface but if you're looking at 480mbps as sufficient, then 6gbps could probably stand to have some overhead and "video data" can just be "data", after all ...

Downsides:

• MIPI is only available in the 0.65mm packages, not the easier-to-layout 0.8mm ones
• You do need to buy a license for the 'Efinity' software, but you do that by buying a $35 'xyloni' board, which gets you a license for everything, and they renew it after a year if you ask
• You'd have to package your data as video data to the hardened IP, but it doesn't look too hard - and you could test out the link by plugging it into a monitor
• Probably yet another weird-FPGA to learn - they're not the most common type of FPGA around

I thought about using them myself for my FPGA<->FPGA data-link over a PCIe slot (not via cable) but I prefer 0.8mm BGAs for layout, and there's plenty of LVDS available for my own use-case.

These are cheap low-end 'Trion' FPGAs, but they're not terrible. The RiscV CPU they offer will get you to ~110MHz for fMax, and if you want more they've relatively recently introduced the 'Titanium' line which push that up to ~350MHz. I think the new chips are still unobtanium though, apart from in dev-kits, which themselves are in short supply...

[asmi]

The question I've been wondering about since the beginning of this thread - why don't you use just regular old school source syncronous LVDS? It's supported by pretty much any FPGAs, it's trivial to implement and scale as needed.

[SpacedCowboy]

*shrug* that's my plan, which I think will be fine because I'm travelling a few inches to a PCIe slot, and maybe a few inches to another FPGA after that, all on connected (if not quite the same) PCB.

I think SiliconWizard wants to push the data out over a few meters of cable, and was concerned about clock/data sync at the end of that.

[free_electron]

sata or displayport cables. send clock over one pair , one tx pair one rx pair.

[asmi]

sata or displayport cables. send clock over one pair , one tx pair one rx pair.

Sata cable only has 2 differential pairs, and there is no requirement for sata or DP (or USB-C) cable to have pairs length-matched because they all use embedded clocks.

[asmi]

I think SiliconWizard wants to push the data out over a few meters of cable, and was concerned about clock/data sync at the end of that.

It can be done if you're using an LDVS cable with matched pairs, and your data rate is not very high, otherwise you will have to use embedded clock and so need to do a clock recovery or oversampling to extract data on a receiving side asynchronously. Infact if you have setup/hold times for your FPGAs on receiving side, you can calculate what kind of length mismatch you can tolerate and what kind of wire speed you can achieve.

[DiTBho]

And it's gonna be at least another 2 years before stock of FPGAs begins to come back to something sorta normal. 

Yup. Today I contacted again the same company for their Xilinx Spartan-7 7S25
(not the chip, their board, I don't want, and I am not able to design and build it)
"Possible to order, delivery time on request"  ... same response from 2020

[SiliconWizard]

I think SiliconWizard wants to push the data out over a few meters of cable, and was concerned about clock/data sync at the end of that.

It can be done if you're using an LDVS cable with matched pairs, and your data rate is not very high, otherwise you will have to use embedded clock and so need to do a clock recovery or oversampling to extract data on a receiving side asynchronously. Infact if you have setup/hold times for your FPGAs on receiving side, you can calculate what kind of length mismatch you can tolerate and what kind of wire speed you can achieve.

Yes, and this is running in circles.

If you want a reasonably robust data link @ around 500 Mbps, for which typical uses are OK with the half-duplex nature (a lot more data pumped in one direction than the other direction), over a single twisted pair, over distances from a few mm to a few meters, using an approach that is easily portable between various models and vendors of FPGAs, using USB PHYs (that themselves are ubiquitous, cheap and use a standard interface) doesn't look so bad to me. We're talking about $1 to $2 in small quantities, and probably under $1 for high quantities, and the ULPI interace, basically 60 MHz SDR, is easily achievable with even the smaller FPGA around. (And as I said, there may be reasons for using small ones here, not just for cost reasons, but also for power consumption, as long as the rest of your design doesn't require anything more powerful. Just compare the typical power consumption of even the smallest Artix-7, for instance, to that of an icE40UP.)

As I already mentioned twice, using gigabit Ethernet PHYs could also be an option (albeit not quite as simple or as cheap) for more bandwidth and longer cables. But requiring at least two pairs.

Of course if you don't need to combine all those requirements, or you simply have different requirements altogether, you have myriads of other options.

[SiliconWizard]

If you're open to repurposing different protocols, Efinix have $10 parts with hardened MIPI CSI2 - 4 data lanes @ 1.5gbps each + a clock lane.

The idea was not to repurpose a different bus/protocol just for the sake of it, but to be cheap and easily available and... portable over a range of parts. Also, not sure what would be the max distance for MIPI? I've never seen it used for anything much longer than flat cables a few cm long or so?

That said, Efinix parts looked interesting but I never got around to evaluating them.

[SpacedCowboy]

apparently 15m - https://www.theimagingsource.com/media/blog/archive/20190603/

[asmi]

If you want a reasonably robust data link @ around 500 Mbps, for which typical uses are OK with the half-duplex nature (a lot more data pumped in one direction than the other direction), over a single twisted pair, over distances from a few mm to a few meters, using an approach that is easily portable between various models and vendors of FPGAs, using USB PHYs (that themselves are ubiquitous, cheap and use a standard interface) doesn't look so bad to me. We're talking about $1 to $2 in small quantities, and probably under $1 for high quantities, and the ULPI interace, basically 60 MHz SDR, is easily achievable with even the smaller FPGA around. (And as I said, there may be reasons for using small ones here, not just for cost reasons, but also for power consumption, as long as the rest of your design doesn't require anything more powerful. Just compare the typical power consumption of even the smallest Artix-7, for instance, to that of an icE40UP.)

Since I'm an engineer, let's inject some practicality into discussion - what are you going to do with 480 Mbps data stream inside such feeble FPGAs, or how it's going to generate such data stream (if it's a trasmitting side)? Especially since you are going to expend like a third to half of available IO pins of ice40Ultra depending on package, so further limiting already very limited external connectivity options. Actually, connectivity (or lack of thereof) has been my biggest problem with ice40Ultra parts, I still have like a dozen or so 5K parts in QFN48 package I've bought years ago in the hope that at some point I will find a use for them, but so far I didn't and they keep collecting dust. Which is why I didn't even bother buying ice40UP parts when they showed up - even though with integrated RAM they are theoretically much more useful.
So - have you done any projects with these devices, and if so can you please give some examples for when they can be useful? Maybe I'm just blind and forcing much more expensive parts onto my customers for no good reason? They don't seem to mind though

[asmi]

apparently 15m - https://www.theimagingsource.com/media/blog/archive/20190603/

If you would actually read the article, it says that they use FPD-Link III for actual transmission over cable, which is basically LVDS. With the kind of tolerances MIPI has (dV is nominally 200mV, which is less than DDR3L!), there is no way it would work over anything longer than a fraction of meter.

15 m Cable Thanks to FPD-Link III
Especially in the automotive sector, however, one is quickly confronted with the problem that standard ribbon cables, such as those used in smartphones between SoC and camera module, rarely allow cable lengths beyond 30 cm. Camera modules in an automotive surround-view application, for example, require cable lengths of several meters. The same often applies to industrial applications where camera modules are being installed into systems. The Flat Panel Display Link III (FPD-Link III) interface from Texas Instruments provides a solution. Designed for the transmission of high-resolution video data for automotive applications (in addition to pure data transmission), the interface offers bidirectional channels for control commands (e.g. for configuring a camera module via I2C or feedback from a touch display), as well as the option of power supply via a single coaxial cable. Such cables are thin, flexible and inexpensive - features that play a decisive role in price-sensitive market segments like the automotive industry. Two additional components are used to transmit the MIPI/CSI-2 signals via FPD-Link III: a serializer that translates from MIPI/CSI-2 to FPD-Link III and a deserializer that translates from FPD-Link III back to MIPI/CSI-2 (Ser-Des). While the serializer is placed directly on the camera module, the deserializer is located near the MIPI/CSI-2 input of the processing SoC. The FPD-Link III path is completely transparent for the user. The Imaging Source recognizes the need for longer transmission systems and now offers, together with its MIPI/CSI-2 modules, FPD-Link III bridges for common embedded systems such as NVIDIA Jetson.

[SpacedCowboy]

My bad. I thought that was a brand of cable, not a transmission protocol/standard. 

[SiliconWizard]

That didn't sound right indeed.

[SiliconWizard]

If you want a reasonably robust data link @ around 500 Mbps, for which typical uses are OK with the half-duplex nature (a lot more data pumped in one direction than the other direction), over a single twisted pair, over distances from a few mm to a few meters, using an approach that is easily portable between various models and vendors of FPGAs, using USB PHYs (that themselves are ubiquitous, cheap and use a standard interface) doesn't look so bad to me. We're talking about $1 to $2 in small quantities, and probably under $1 for high quantities, and the ULPI interace, basically 60 MHz SDR, is easily achievable with even the smaller FPGA around. (And as I said, there may be reasons for using small ones here, not just for cost reasons, but also for power consumption, as long as the rest of your design doesn't require anything more powerful. Just compare the typical power consumption of even the smallest Artix-7, for instance, to that of an icE40UP.)

Since I'm an engineer, let's inject some practicality into discussion - what are you going to do with 480 Mbps data stream inside such feeble FPGAs, or how it's going to generate such data stream (if it's a trasmitting side)?

It's just practically about 50 MBytes/s, which is really not that much. No problem whatsoever.

I have a handful of applications for that for which those FPGAs would be plenty. Basically acting as some kind of bridge for data acquisition. One class of such applications right now is for transmitting multi-channel digital audio with some custom protocol. An iCE40UP would be more than enough for this, and the power consumption is a great asset. ULPI requires 12 IOs, you have about 24 left or so for interfacing to DACs/ADCs and some accessory functions. But if I need more IOs, I can always use the MachXO2/3 lines for similar performance and similarly low power consumption. And, as I said, for devices requiring more, I can use more powerful FPGAs. The whole system can consist of devices with a varying degree of complexity.

I'll be glad to explain what I have in mind exactly, without giving too many details though, but that wasn't the point of this thread. If some of you can't see the point, that doesn't necessarily mean there isn't any. Ah, humility again.

[asmi]

It's just practically about 50 MBytes/s, which is really not that much. No problem whatsoever.

That's actually quite bit for these devices. I would to hear more practical examples of how to generate or handle that kind of bitrate in these devices.

I have a handful of applications for that for which those FPGAs would be plenty. Basically acting as some kind of bridge for data acquisition. One class of such applications right now is for transmitting multi-channel digital audio with some custom protocol. An iCE40UP would be more than enough for this, and the power consumption is a great asset. ULPI requires 12 IOs, you have about 24 left or so for interfacing to DACs/ADCs and some accessory functions. But if I need more IOs, I can always use the MachXO2/3 lines for similar performance and similarly low power consumption. And, as I said, for devices requiring more, I can use more powerful FPGAs. The whole system can consist of devices with a varying degree of complexity.

<Update: Fixed numbers  >
A single stream of raw audio at 192kHz@24bit is only 768 kbit/s4.6 Mbps, for 480 Mbit/s you can have over 600over 100 channels, which is obviously not realistic. So if we take somewhat more realistic 8 channels, that's only about 636.8 Mbps Mbit/s, which is something that even an average RS485 transceiver can handle without too much fuss.

I'll be glad to explain what I have in mind exactly, without giving too many details though, but that wasn't the point of this thread. If some of you can't see the point, that doesn't necessarily mean there isn't any. Ah, humility again.

I generally dislike theoretical discussions because they tend to devolve into pointless debates over spherical cows in the vacuum, which is why I always look at the subject from a practical standpoint. Sure I can set up a high-speed channel between two ice40U's by using a bunch pf their DDR primitives (I seem to recall they can go up to 500 Mbps), but what's the point of it? What kind of data can I send over such channel, and where to get it? These answers are the most important ones, once you have them, you will usually have a better idea of how to go about designing a communication channel.

[BrianHG]

A single stream of raw audio at 192kHz@24bit is only 768 kbit/s, for 480 Mbit/s you can have over 600 channels, which is obviously not realistic. So if we take somewhat more realistic 8 channels, that's only about 6 Mbit/s, which is something that even an average RS485 transceiver can handle without too much fuss.

Please redo your math.

[langwadt]

A single stream of raw audio at 192kHz@24bit is only 768 kbit/s, for 480 Mbit/s you can have over 600 channels, which is obviously not realistic. So if we take somewhat more realistic 8 channels, that's only about 6 Mbit/s, which is something that even an average RS485 transceiver can handle without too much fuss.

Please redo your math.

only off by a factor of 6

[BrianHG]

A single stream of raw audio at 192kHz@24bit is only 768 kbit/s, for 480 Mbit/s you can have over 600 channels, which is obviously not realistic. So if we take somewhat more realistic 8 channels, that's only about 6 Mbit/s, which is something that even an average RS485 transceiver can handle without too much fuss.

Please redo your math.

only off by a factor of 6

Shhh...  Let him work that out.
And with all overhead, it's higher.

[asmi]

Shhh...  Let him work that out.

128 kHz x 24 bits/sample ~ 4.6 Mbit/s, 480 / 3 = 104 channels - still too much. for 8 channels 4.6 * 8 = 36.8 Mbit/s is still within reach for RS485.

And with all overhead, it's higher.

What overhead would you have in a raw audio stream? It's just an endless stream of audio samples

[BrianHG]

Shhh...  Let him work that out.

128 kHz x 24 bits/sample ~ 3 Mbit/s, 480 / 3 = 160 channels - still too much. for 8 channels 3 * 8 = 24 Mbit/s is still within reach for RS485.

And with all overhead, it's higher.

What overhead would you have in a raw audio stream? It's just an endless stream of audio samples

Mistakes again....
192khz, not 128khz...
Also, the overhead is on the USB side.  Plus, you may have checksum data with your audio, plus start and stop bits when using a serial audio connection.
There may also line in audio in parallel which might need bus steering and handshaking unless you have a dedicated up channel.

[asmi]

Also, the overhead is on the USB side.  Plus, you may have checksum data with your audio, plus start and stop bits when using a serial audio connection.

We're looking at fully-custom channel, so no USB overhead. A checksum? Have you seen any real-time stream protocols with checksums? It's pointless. For framing you can use some "comma" sequence which can not be found in a real audio stream (like FFFFFF/000000/FFFFFF), or add 25% overhead and use classic 8b/10b encoding.

There may also line in audio in parallel which might need bus steering and handshaking unless you have a dedicated up channel.

Again, we're talking about custom channel. RS485's 50 Mbps is a lot for audio, there is quite a bit of margin even for 8 channels. And RS485 is just an example, there are plenty of mid-bandwidth options (in 50-100 Mbps range), which begins from simple pin wiggling with no external parts at all.
My math inaptitude notwithstanding, my larger question still stands - what exactly can generate or process 480 Mbps data stream inside 4K LUT (actually 3520) FPGA with 4 DSP blocks and 80k of memory?

[BrianHG]

There may also line in audio in parallel which might need bus steering and handshaking unless you have a dedicated up channel.

Again, we're talking about custom channel. RS485's 50 Mbps is a lot for audio, there is quite a bit of margin even for 8 channels. And RS485 is just an example, there are plenty of mid-bandwidth options (in 50-100 Mbps range), which begins from simple pin wiggling with no external parts at all.
My math inaptitude notwithstanding, my larger question still stands - what exactly can generate or process 480 Mbps data stream inside 4K LUT (actually 3520) FPGA with 4 DSP blocks and 80k of memory?

The only FPGA I recommended was the 8$ (was 5$ before chip shortage) Lattice part where over 17000 parts of stock existed was a 24K LE with 1meg ram in it.  This part with a ULPI usb phy in 6 wire interface mode is large and fast enough to create a true-HD 8 channel in, 8 channel out audio interface.  I would still recommend added external ram as 1mb for 16 channel true-HD audio is a tiny 0.01 second buffer.

[asmi]

The only FPGA I recommended was the 8$ (was 5$ before chip shortage) Lattice part where over 17000 parts of stock existed was a 24K LE with 1meg ram in it.  This part with a ULPI usb phy in 6 wire interface mode is large and fast enough to create a true-HD 8 channel in, 8 channel out audio interface.  I would still recommend added external ram as 1mb for 16 channel true-HD audio is a tiny 0.01 second buffer.

Well you've got to follow the discussion. We're talking about ince40Ultra and UltraPlus, the largest of former family having stats as I posted.
Oh btw - what the hell is "true-HD" when it comes to audio?

[BrianHG]

Oh btw - what the hell is "true-HD" when it comes to audio?

Sorry, my bad.  True-HD audio 'usually' refers to uncompressed 192k 24bit audio.  However, some may say 384k 24 bit, or 96k 24 bit as well as some 32bit formats.  But you are right.  It can be a few different bitrates & depth, jut not 44.1k 16bit.